Optional不能直接替代null判断，需用ofNullable()而非of()包装；避免get()，优先使用orElse()等安全方法；慎用于字段和序列化场景。
Optional 不能直接替代 null 判断
很多人以为只要把 String 换成 Optional<string></string>，空指针就自动消失了——其实不是。如果方法返回 null 后你手动用 Optional.of(null) 包装，运行时立刻抛 NullPointerException。正确做法是只对可能为 null 的值用 Optional.ofNullable()。
-
Optional.of(null)→ 直接炸（不推荐） -
Optional.ofNullable(null)→ 返回Optional.empty()（安全） - getter 方法返回
Optional是合理设计；但字段本身声明为Optional<t></t>通常属于滥用（增加内存开销、序列化麻烦）
链式调用中 get() 是最大陷阱
get() 看起来方便，但一旦 Optional 是空的，它会立刻抛 NoSuchElementException，和原始的空指针异常一样危险，只是错误类型不同。真正安全的写法是用 orElse()、orElseGet() 或 ifPresent()。
-
opt.get()→ 危险！等价于裸奔调用.toString() -
opt.orElse("default")→ 安全，适合简单默认值 -
opt.orElseGet(() -> heavyCompute())→ 延迟执行，避免无谓计算 -
opt.map(String::length).orElse(0)→ 支持链式转换，且全程不暴露get()
Stream 中配合 filter 和 map 更自然
在集合处理场景下，Optional 最常被误用为“单个元素容器”。其实它和 Stream 天然契合：一个 Optional<t></t> 可以看作最多含 1 个元素的流，用 stream() 方法转成 Stream<t></t> 后，就能无缝接入现有流式逻辑。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
-
optional.stream().filter(...).map(...).findFirst()→ 避免嵌套isPresent()判断 - 比手写
if (opt.isPresent()) { ... opt.get() ... }更函数式、更易组合 - 注意
optional.stream()对empty()返回空流，不会报错，也不会触发副作用
第三方库（如 Vavr）提供更严格的替代方案
JDK 的 Optional 被设计为“仅用于返回值”，不可序列化、不可修改、没有 flatMap 以外的高级操作。如果你需要链式 fallback、模式匹配或跨线程传递语义，JDK 版本很快会力不从心。
立即学习“Java免费学习笔记（深入）”；
- Vavr 的
Option支持toJavaOptional()互转，且自带getOrElseThrow()、fold()等方法 - Lombok 的
@UtilityClass+ 自定义工具类也能补足常见缺失（比如OptionalUtils.coalesce(a, b, c)） - Spring Framework 5+ 的
org.springframework.util.StringUtils.hasText()等工具，其实比硬套Optional更贴近业务意图
真正难的不是怎么用 Optional，而是判断什么时候不该用——比如 DTO 字段、JSON 序列化、MyBatis 映射、日志上下文传递，这些地方强行塞 Optional 只会让调试更痛苦。
