本文探讨为何不应将 optional 作为方法入参，分析常见误用场景（如 orelse(null)），并提供三种实用、可落地的重构策略：重载方法、职责拆分、以及何时可接受现状。
在 Java 开发中，Optional
最典型的反模式是为调用而临时包装：
OptionaloptionalBook = findBook(bookId); doSomething(optionalBook.orElse(null), someOtherStuff); // ❌ 隐式引入 null，削弱 Optional 的防护价值
这行代码看似简洁，实则消解了 Optional 的全部意义——你主动将空安全的容器降级为易错的裸引用，并迫使 doSomething 内部重复做 null 检查（如 if (book != null) { ... }），既冗余又脆弱。
✅ 推荐方案一：方法重载（最常用、最直观）
若业务逻辑天然支持“有书”和“无书”两种路径，直接提供两个明确签名的方法：
void doSomething(Book book, SomeOtherStuff stuff); // 主路径：Book 必然存在 void doSomething(SomeOtherStuff stuff); // 备选路径：Book 缺失时的轻量处理
调用方清晰、无歧义：
findBook(bookId).ifPresentOrElse(
book -> doSomething(book, someOtherStuff),
() -> doSomething(someOtherStuff)
);✅ 推荐方案二：职责分离（面向复杂流程）
当 doSomething 内部逻辑可解耦（例如包含预处理、核心 Book 相关操作、后置通用处理），应主动拆分：
void prepare(); // 如日志、上下文初始化 void processBook(Book book); // 纯 Book 依赖逻辑 void finalize(SomeOtherStuff stuff); // 与 Book 无关的收尾工作
优势在于：
- 支持批量处理（先统一 prepare()，再并行 processBook()，最后统一 finalize()）；
- 提升单元测试粒度（processBook 可独立验证，无需模拟 Optional）；
- 显式暴露控制流，降低认知负荷。
⚠️ 方案三：接受现状（需审慎评估）
若 doSomething 调用频次极低、逻辑极简、且当前 orElse(null) 已被充分测试并稳定运行，强行重构可能得不偿失。此时应：
- 在方法注释中明确标注 @param book may be null；
- 确保内部 null 检查严格（建议用 Objects.requireNonNullElse(book, defaultBook) 或 Optional.ofNullable(book) 封装后续链式操作）；
- 将此视为技术债，在下次功能迭代时优先重构。
总结：Optional 不是“null 的语法糖”，而是 API 设计的语言。拒绝将其作为参数，本质是坚持“输入即契约”——方法应清晰声明它真正需要什么。从 findBook() 返回 Optional 是优雅的；但让下游方法被迫消费 Optional，则是设计断层的信号。优先选择重载或拆分，让代码语义自解释，比任何 orElse(null) 都更健壮、更可持续。
