optional应仅用于方法返回值，禁用于参数和字段；链式调用不超过两层；优先用orelseget避免无效对象创建；简单判空直接使用null检查更高效。
Optional 本意是让空值语义更清晰、让调用方无法忽视“可能无值”这一事实，但一旦脱离设计初衷，就容易变成套娃式包装，反而让逻辑变模糊、调试变困难。避免滥用的关键，在于守住它的边界：它只该出现在方法返回值位置，且链式调用要控制深度、拒绝嵌套。
只用于返回值，不进参数、不进字段
把 Optional 当作入参或类成员，会强迫调用方提前包装、使用者额外解包，纯属增加冗余。
- 构造器接收
Optional<string> postcode</string>，不如直接接收String postcode（允许为 null），再由方法内部决定是否包装成 Optional 返回 - Bean 字段声明为
Optional<string> zip</string>不仅不可序列化，还让 JSON 序列化、ORM 映射等基础能力失效
链式调用别超过两层
map/flatMap 链过长会让代码像“回调地狱”，也暴露模型设计问题。
- 获取用户城市名称，写成这样已足够清晰：
String city = Optional.ofNullable(user).map(User::getAddress).map(Address::getCity).orElse("未知城市"); - 若再加
.map(City::getName)或嵌套flatMap，说明 Address 里又嵌了 Optional——此时更该重构数据结构，而不是靠 Optional 掩盖设计缺陷
默认值优先用 orElseGet，不用 orElse
不是可读性问题，但影响性能感知。频繁 GC 会让线上日志看起来“莫名其妙变慢”，间接拖累排查效率。
-
orElse(new ExpensiveObject())每次都创建实例，哪怕 Optional 有值 -
orElseGet(() -> createExpensiveObject())是懒加载，只在真正需要时才执行 Supplier
简单空值判断，直接判空更直白
Optional 是语法糖，不是银弹。不是所有场景都需要它。
- 方法内部临时变量判空：
status == null ? "PENDING" : status比Optional.ofNullable(status).orElse("PENDING")更轻量、更易扫描 - 单层判空且分支明确：
if (user != null) { ... }比包装再ifPresent更符合直觉 - 底层工具类或性能敏感路径（如网关、计数器），避免无谓对象分配
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
