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