Optional 的顶层设计原则是用类型系统显式表达“值可能存在，也可能不存在”，仅作返回值不作参数或字段；它不替代 null 的合理语义，只封装业务上本应存在却因缺失而暂缺的不确定性，强制调用方处理空分支，不参与数据建模。
Optional 的顶层设计原则不是“消灭 null”，而是用类型系统显式表达“值可能存在，也可能不存在”这一语义。它把原本隐含在代码逻辑里的空值假设，变成编译期可感知、调用时必须处理的契约。
只作返回值，不作参数或字段
这是最核心的边界。Optional 是给调用方看的“协议信号”——告诉对方：“这个结果可能没有，请别直接用”。一旦把它塞进方法参数或类字段，就扭曲了语义：
- 作为参数：调用方还得先
.orElse(null)或.get()，反而增加一层无意义包装 - 作为字段：破坏序列化兼容性（如 JSON 序列化为
null还是{}？）、干扰 ORM 映射、让调试器显示冗余嵌套 - 正确姿势：
public Optional<User> findUserById(Long id)—— 查不到就自然为空，调用方一眼明白要处理分支
不替代 null 的合理语义，只封装“不确定性”
null 本身有语义：比如 Map.get(key) 返回 null 表示“键不存在”，这是清晰、通用、无需包装的约定。Optional 不该强行覆盖这类场景：
- 不要写
Optional.ofNullable(map.get(key))再暴露出去——map 本身已表达“可能无值” - 适合封装的是“业务上本应存在，但因数据缺失/条件不满足而暂缺”的值，例如：查询数据库未命中、远程调用超时降级、配置项未设置
- 关键判断：如果去掉 Optional，调用方是否容易漏掉空检查？如果是，就值得封装；如果本来就是标准 API 的明确语义，就不必叠床架屋
强制链式处理，拒绝裸 get()
Optional 的 API 设计是“防呆”的：它不提供便捷的“取值”出口，逼你选择如何应对空值。这正是顶层设计的用心所在：
立即学习“Java免费学习笔记（深入）”；
-
get()是反模式——它把NullPointerException换成NoSuchElementException，没解决根本问题 - 真正安全的路径只有三条：
orElse/orElseGet（提供默认）、ifPresent（仅存在时操作）、map/flatMap（转换并延续流程） - 链式调用天然支持“短路”：任意一环返回
Optional.empty()，后续操作自动跳过，不用层层 if 判空
不参与数据建模，只服务流程契约
Optional 是运行时流程的“状态携带者”，不是数据结构的一部分：
- DTO、VO、Entity 中禁止出现
private Optional<String> name;—— 它们描述事实，不是描述“查找动作的结果” - REST 接口返回值也不该是
ResponseEntity<Optional<User>>—— HTTP 状态码（如 404）和空 body 已足够表达“未找到”，加 Optional 只会让客户端困惑 - 它的舞台在 service 层内部、跨模块调用边界，用来隔离和显化“不确定性”的传播路径
