Optional不是null替代品，而是为明确表达“可能无值”的计算链设计；禁用其作参数、字段、DTO及序列化场景，优先使用函数式操作而非isPresent()。
别用 Optional 当返回值的“空值占位符”来掩盖业务逻辑缺陷——它不是 null 的替代品，而是为明确表达“可能无值”的计算链而设计的。
Optional 不能作为方法参数或字段类型
把 Optional 当成入参或类成员，等于主动引入额外的 isPresent() 判断和潜在的 NullPointerException（比如传入 null 构造 Optional.of(null) 会直接抛异常）。
常见错误场景：
- 写成
public void process(Optional—— 调用方仍可能传data) Optional.empty()或null，语义模糊 - 在实体类里声明
private Optional—— 序列化、ORM 映射、日志打印全会出问题name;
正确做法：参数保持原始类型（如 String），由调用方决定是否包装；字段也用原始类型，需要时再用 Optional.ofNullable() 包一层做计算。
立即学习“Java免费学习笔记（深入）”；
避免链式调用中混用 isPresent() + get()
写成 if (opt.isPresent()) { return opt.get().trim(); } 就失去了 Optional 的价值——这和直接判 null 没本质区别，还多了一层对象开销。
应该优先使用函数式操作：
- 有默认值？用
opt.orElse("default")或opt.orElseGet(() -> computeDefault()) - 要转换？用
opt.map(String::trim).map(String::toUpperCase) - 要过滤？用
opt.filter(s -> s.length() > 0) - 要抛异常？用
opt.orElseThrow(() -> new IllegalArgumentException("missing"))
注意：orElseGet() 是懒求值，orElse() 是立即执行，大数据量或高开销计算时别误用前者。
从 Map 或 Stream 获取 Optional 要小心空集合语义
map.get(key) 返回 null，所以常写成 Optional.ofNullable(map.get(key)) —— 这没问题。但容易忽略的是：Optional.empty() 和 “key 不存在” 是等价的，而 “key 存在但 value 为 null” 也会变成 Optional.empty()，二者无法区分。
类似地，stream.findFirst() 返回 Optional 是合理的，但 stream.collect(Collectors.toList()).get(0) 再包一层 Optional 就属于反模式——既损失性能，又掩盖了本该用 findFirst() 表达的意图。
关键判断点：
- 这个“可能为空”是 API 合约的一部分（如
Map.get、Stream.findAny），还是你人为加的包装？ - 下游是否真的需要组合多个
Optional操作（比如flatMap穿透嵌套）？如果不是，直接判null更直白
Optional 与 Lombok 的 @NonNull/@Nullable 注解不兼容
Lombok 的 @NonNull 会在生成的构造/Setter 中插入 Objects.requireNonNull()，但对 Optional 字段无效——因为 Optional 本身可以为 null，且 Optional.empty() 不等于 null。这就导致注解语义断裂。
更麻烦的是 Jackson 反序列化：如果 JSON 字段缺失，Lombok + Optional 字段可能得到 null，而非 Optional.empty()，触发 NPE。
务实方案：
- 禁用 Lombok 对
Optional字段的@NonNull处理（用@NonNull(onMethod_ = @_(...))排除） - Jackson 中显式配置
DeserializationFeature.FAIL_ON_NULL_FOR_PRIMITIVES并配合@JsonSetter(nulls = Nulls.SKIP) - 统一在 service 层用
Optional.ofNullable()包装外部输入，而不是依赖框架自动转
最常被忽略的一点：Optional 是不可序列化的（没有实现 Serializable），哪怕你强行让它实现，在分布式缓存或 RPC 场景下也极易因版本不一致导致反序列化失败——别把它塞进 DTO 或远程接口返回值里。
