Optional 不是可空容器，禁止直接 get()；不可作字段或集合元素；必须用 ofNullable() 处理可能为 null 的值；应发挥其函数式链式处理能力，避免命令式嵌套。
把 Optional 当成“可空容器”直接取值
很多人看到 Optional 就以为是“带 null 检查的包装类”，于是写
String s = optional.get();，结果一遇到空值立刻抛
NoSuchElementException。这不是安全用法，而是把风险从 NullPointerException 换成了另一个运行时异常。
真正该做的是：用 isPresent() + get() 组合（仅限简单逻辑），或更推荐用 orElse()、orElseGet()、ifPresent() 等终端操作。
-
orElse(null)是反模式——它让Optional失去意义，等价于裸写obj != null ? obj : null -
orElseGet(() -> heavyComputation())比orElse(heavyComputation())更安全，后者会在任何情况下都执行计算 - 不要在流式处理中用
get()：比如list.stream().map(Optional::get).collect(...)，一旦某个元素为empty，整个流就崩了
在实体字段或集合里滥用 Optional
Optional 不是数据建模工具。JDK 明确不建议将 Optional 作为字段类型（见 官方文档：“It is not intended for use as a field type”）。原因很实在：
- 序列化失败：Jackson 默认不支持序列化
Optional字段，Gson 会输出{}或报错 - ORM 框架不识别：JPA/Hibernate 无法映射
Optional到数据库列，会抛MappingException - JSON API 不兼容：前端收到
{"name":{"present":true,"value":"Alice"}}这种结构根本没法消费 - 集合嵌套灾难：
List是典型信号——说明原始数据源本就设计混乱，该修复的是上游逻辑，不是加一层 Optional>
用 Optional.of(null) 初始化
这个调用一定会触发 NullPointerException，因为 of() 要求参数非空；想允许 null，必须用 ofNullable()。
立即学习“Java免费学习笔记（深入）”；
常见错误场景：
- 从 Map 取值后直接
Optional.of(map.get("key"))—— 若 key 不存在，get()返回null，of(null)立刻炸 - DAO 层返回
Optional，但实现里写了return Optional.of(userDao.findById(id));，而findById本身可能返回null - 误以为
of()和ofNullable()行为一致，只因 IDE 自动补全选错了
正确姿势永远是：不确定是否为 null 的地方，无条件用 ofNullable()。
忽略 Optional 的函数式语义，硬套命令式流程
Optional 的设计初衷是支持链式、声明式处理，比如 user.flatMap(this::findProfile).map(Profile::getEmail).filter(this::isValidEmail)。但如果写成：
OptionaluserOpt = findUser(id); if (userOpt.isPresent()) { User user = userOpt.get(); Optional profileOpt = findProfile(user.getId()); if (profileOpt.isPresent()) { String email = profileOpt.get().getEmail(); if (isValidEmail(email)) { sendEmail(email); } } }
这等于把 Optional 当成更啰嗦的 if (x != null)，还损失了组合能力。更糟的是，这种写法极易漏掉空分支处理，反而比原始 null 更难维护。
复杂嵌套逻辑下，宁可拆成独立方法 + 明确的 early-return，也不要堆砌 isPresent() 嵌套。真正值得链式处理的，是那些能自然表达“转换→过滤→降维”的场景，比如解析配置、拼接路径、校验状态流转。
最容易被忽略的一点：Optional 不是线程安全的容器——它不可变，但不代表持有它的对象线程安全。别把它当共享状态缓存用，尤其别放在 static 字段里反复 set/reset。
