Optional 应仅用于明确表达“值可能存在也可能不存在”的返回值，不可作字段、参数或集合元素；避免 orElse(null) 和 stream 中滥用 filter+get，优先用 map/flatMap/ifPresent；RPC、JSON、DB 场景禁用 Optional。
Java 中 Optional 本意是为避免 null 检查而生，但用错反而让代码更难懂、更易出 bug。关键不是“用了 Optional”，而是“用得对不对”。
别把 Optional 当作 null 的包装器
很多人误以为只要把可能为 null 的值塞进 Optional 就算“防空”了——这是最大误区。比如：
Optional<String> name = Optional.ofNullable(user.getName());
如果 user 本身是 null，这行就直接抛 NullPointerException。
正确做法是：Optional 应该只用于明确表达“值可能存在也可能不存在”语义的返回值，而不是中间变量或参数。
- ✅ 接口方法返回
Optional<User>表示“可能查不到用户” - ❌ 不要用
Optional<String>做字段、方法参数或集合元素 - ❌ 避免在构造对象时用
Optional包装属性（如private Optional<String> email;）
慎用 orElse(null) 和 orElseGet(() -> null)
这两者看似安全，实则悄悄把 Optional 的语义抹掉了——又回到了 null 老路。
立即学习“Java免费学习笔记（深入）”；
userRepository.findById(id).orElse(null) 等价于没用 Optional，还多了一层封装。
- ✅ 优先用
ifPresent()、map()、flatMap()做链式处理 - ✅ 必须提供默认值时，用有意义的默认对象（如
orElse(AnonymousUser.INSTANCE)） - ✅ 真需要
null，说明设计有问题——考虑是否该抛异常（orElseThrow()）或重构接口
别在 stream 中滥用 Optional 的 filter/map
写成这样很常见，但逻辑绕、可读性差：
✘ 不推荐：list.stream()<br> .map(this::findUser)<br> .filter(Optional::isPresent)<br> .map(Optional::get)<br> .forEach(System.out::println);
其实 findUser 返回 Optional，本身就暗示“可能找不到”，stream 更自然的写法是：
- ✅ 改成
flatMap：.flatMap(u -> findUser(u).stream()) - ✅ 或提前过滤：先
filter再map，避免嵌套判断 - ✅ 如果 findUser 是耗时操作，注意 flatMap 不会短路，必要时考虑先 collect 再处理
警惕 Optional 的性能与序列化陷阱
Optional 是不可变容器，每次 map 都新建实例；它没有实现 Serializable（Java 9+ 才加了 transient 支持），在网络调用或持久化场景中容易出错。
- ✅ RPC 接口、JSON 返回、数据库实体中，坚决不用 Optional 字段
- ✅ 日志、监控等非核心路径，不必强求 Optional，简单判空更直白
- ✅ 单元测试里验证 Optional 行为时，用
assertTrue(opt.isPresent())比assertNotNull(opt.get())更准确
