Optional.ifPresentOrElse在Java 9+中需确保JDK版本≥9、Maven配置source/target≥9，且第二个参数必须是Runnable而非Consumer，否则编译失败；它性能与ifPresent+else几乎无差异，但空分支lambda仍会实例化。
Optional.ifPresentOrElse 在 Java 9+ 中怎么写才不报错
这个方法只在 Java 9 及以上版本可用，Java 8 项目里直接调用会编译失败，错误信息是 cannot resolve method ifPresentOrElse。它本质是 ifPresent 的增强版，补上了“值不存在时执行什么”的逻辑，避免手动判空写 if (opt.isPresent()) ... else ...。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 确认 JDK 版本：运行
java -version，且项目编译和运行都需 ≥ Java 9 - Maven 项目需检查
source和target是否设为9或更高（如11） - 不要在 Optional 为
null时调用它——ifPresentOrElse本身不处理外层 null，会抛NullPointerException
lambda 参数类型不匹配导致编译失败的典型场景
ifPresentOrElse 接收两个参数：一个是 Consumer<t></t>（值存在时执行），另一个是 Runnable（值为空时执行）。常见错误是把第二个参数也写成 Consumer，比如传 System.out::println，结果编译报错 no instance of type variable T exists so that Consumer<t> conforms to Runnable</t>。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 值存在分支：用
opt.ifPresentOrElse(v -> System.out.println("Got: " + v), () -> System.out.println("Empty")) - 值为空分支必须是无参无返回的
() -> { ... }或已有Runnable实例，不能带参数 - 如果想在空分支里记录日志并带上下文，得提前把变量捕获进 lambda，比如
String id = "user-123"; opt.ifPresentOrElse(..., () -> log.warn("Missing config for {}", id))
和 ifPresent + else 手动判断比，性能差吗
几乎没有差异。底层就是一次 isPresent() 判断加分支跳转，没有额外对象创建或反射开销。但要注意：它不会短路，两个 lambda 表达式体在编译期就确定了，只是运行时执行哪一支。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 别在空分支的
Runnable里放重操作（比如 IO、锁、复杂计算），因为每次调用都会构造该 lambda 实例（尽管没执行） - 如果空分支逻辑较重，且被高频调用，建议提取为命名
Runnable静态常量，避免重复实例化 - 它不改变 Optional 内部状态，也不影响后续链式调用，可放心接
map、filter等
替代方案：为什么有人还在用 isPresent() + if/else
主要是兼容性和可读性权衡。有些团队禁止使用 Java 9+ 新 API；有些场景需要在 else 分支里访问多个变量或做复杂控制流（比如 break、continue、throw 检查异常），而 Runnable 限制太死。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 如果空分支要 throw
IllegalArgumentException，别硬套ifPresentOrElse，直接opt.orElseThrow(() -> new IllegalArgumentException("..."))更自然 - 嵌套 Optional 场景下，
ifPresentOrElse容易让缩进变深、可读性下降，此时扁平化用map+orElse可能更清晰 - 单元测试中，对空分支做 verify 时，用传统 if 更容易打桩或断言分支是否执行——
ifPresentOrElse的 Runnable 是黑盒执行，mock 需额外包装
真正容易被忽略的是：它解决的不是“有没有值”，而是“有没有统一入口处理两种情况”。一旦开始混合使用 isPresent、orElseThrow、ifPresentOrElse，逻辑分散反而更难维护。
