关于Optional.ofNullable后map中使用obj而非x调用方法的疑问

先看你给出的代码：

public void method(MyObject obj) {
    String value = Optional.ofNullable(obj)
                           .map(x -> obj.doSomething())
                           .orElse(MyObject.DEFAULT_VALUE);

}

你提到在当前Optional.ofNullable的场景下，x -> obj.doSomething()和x -> x.doSomething()运行结果一致，这个判断是对的——因为ofNullable只会在obj非null时执行map里的Lambda，此时obj和x指向同一个对象。但二者存在不少值得注意的差异：

• 语义清晰度
  x -> x.doSomething()完全贴合Optional.map的设计逻辑：对Optional内部包裹的非null元素进行转换操作，读代码的人能立刻理解是在处理Optional中的对象。而x -> obj.doSomething()完全忽略了Lambda参数x，语义上非常突兀，会让其他开发者疑惑“为什么不用x？是不是笔误？”，无端增加理解成本。

• 代码规范与潜在风险
  忽略Lambda参数的写法会被多数静态代码检查工具（如SonarLint）标记为代码异味，属于不符合规范的写法。另外，如果后续代码逻辑调整（比如obj变成可变的成员变量，或者在Optional创建后修改obj的引用），x -> obj.doSomething()会意外使用修改后的obj，而x -> x.doSomething()始终指向Optional最初包裹的对象，风险更低。

• 场景扩展性
  如果后续把这段逻辑迁移到Stream流处理（比如遍历集合元素），或者把Optional.ofNullable换成Optional.of（逻辑调整后的场景），x -> obj.doSomething()会直接出错——比如Stream中所有元素都会调用同一个obj的方法，而非当前遍历的元素；而x -> x.doSomething()可以无缝适配这些场景，不需要修改Lambda逻辑。

综上，x -> x.doSomething()更值得采用，它不仅语义清晰、符合代码规范，还能规避潜在风险，同时具备更好的扩展性。

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