getOrElse与match的效率对比：该说法是否属实？

嘿，这个问题我太有共鸣了——之前也听人念叨过getOrElse比手写match更高效，一开始还特意去扒了源码和字节码，现在给你拆解清楚：

首先得敲个黑板：在Scala标准库的Option场景下，这俩在效率上几乎没差别，甚至很多时候编译器会把它们编译成完全一样的字节码。

• 先看标准库源码实锤：Option的getOrElse本身就是用match实现的！你翻一下Scala标准库的Option类，它的getOrElse方法大概是这么写的：

  def getOrElse[B >: A](default: => B): B = this match {
    case Some(x) => x
    case None => default
  }
  

  说白了，getOrElse就是官方给你封装好的match语法糖，本质上是一回事。

• 那“更高效”的说法哪来的？可能是早年Scala版本的遗留传闻？比如Scala 2.10之前的编译器对模式匹配的优化没那么到位，但现在主流的Scala 2.13+、Scala 3版本里，编译器会做内联、分支优化，两种写法的字节码输出基本一致。

• 极端场景下有没有差异？比如你的默认值是个复杂表达式——放心，getOrElse的传名参数（=> B）和你在match的None分支里直接写表达式，都是延迟求值，只有走到None分支才会计算，性能上没区别。

• 唯一可能有差异的情况：如果你自己写了个类似Option的自定义类，并且给它的getOrElse做了特殊优化（比如不用match，改用更轻量的分支判断），那可能会有区别，但这和标准库的Option没关系。

总结下来：标准库的Option.getOrElse和直接手写match模式在效率上没有本质差异，所谓“更高效”的说法要么是过时的老黄历，要么是对自定义场景的误传。要是实在不信，你可以把两种写法编译后用javap反编译看看，字节码几乎一模一样。

内容的提问来源于stack exchange，提问作者clo_jur