应使用 Optional.ofNullable() 包装可能为 null 的源头对象，避免 Optional.of() 抛 NPE；链式调用优先用 orElse()/orElseGet() 收口，禁用 get()；Optional 仅用于方法返回值，不可作字段或参数；map() 内函数不可返回 null，嵌套过深需拆解。
用 Optional.ofNullable() 替代裸 null 判断
直接在可能为 null 的对象上链式调用方法（比如 son.getParent().getUsername()）是空指针高发区。最稳妥的起点是把源头值包进 Optional.ofNullable() —— 它不会抛异常，无论传入的是真实对象还是 null，都返回一个合法的 Optional 实例。
常见错误是误用 Optional.of()：一旦参数为 null，它立刻抛 NullPointerException，反而引入新风险。
-
Optional.ofNullable(son)✅ 安全，推荐作为默认选择 -
Optional.of(son)❌ 仅限你 100% 确认son非空时使用 -
Optional.empty()✅ 显式表达“此处无值”，比返回null更具语义
链式调用中慎用 get()，优先选 orElse() 或 orElseGet()
get() 是 Optional 最危险的方法：只要值不存在，必抛 NoSuchElementException。它和裸 if (x != null) x.method() 一样，把空值检查责任推给了调用方，完全违背了 Optional 的设计初衷。
真正安全的做法是用终结方法收口：
-
orElse("default")：适合简单默认值，开销小 -
orElseGet(() -> computeDefault())：适合默认值计算较重（比如查数据库、IO），只在需要时执行 -
orElseThrow(() -> new IllegalArgumentException("missing"))：明确表达“此处本不该为空”，比静默返回默认值更利于排查问题
避免把 Optional 当作字段或方法返回类型滥用
Optional 不是万能 null 替代品。它的设计定位是“**临时容器**”，用于方法内部流程控制或作为**返回值**表达“结果可能为空”——但它本身不是数据模型的一部分。
以下做法会埋下隐患：
将后端 Java 接口文档转换为前端 TypeScript 类型定义（interface / type）。输入：飞书文档、Spring Boot 接口文档、Swagger/OpenAPI、手写 API 文档等。输出：包含请求参数与响应结果的 .md 文件，含完整 JSDoc 注释。触发关键词：Java 转 TS、接口转换、生成前端类型、接口文档转 TypeScript、DTO/VO/BO 转 interface、后端文档转前端类型、生成接口类型、类型定义生成。
- 在实体类中声明
private Optional❌name; Optional未实现Serializable，序列化失败；且破坏了 POJO 的纯粹性 - 写一个方法返回
Optional，但调用方又立刻.get()强取 ❌ 白套一层，还掩盖了空值语义 - 层层传递
Optional参数，如process(Optional❌ 把空值处理责任甩给下游，增加理解成本input)
正确姿势是：只在**返回值**场景用 Optional，且调用方必须用 orElse 类方法消费它。
嵌套对象访问别硬写多层 map()，注意 null 中断点
像 Optional.ofNullable(son).map(Person::getParent).map(Person::getUsername).orElse("--") 这种链式写法很优雅，但前提是每一步的中间对象（son、getParent() 返回值）都可能为 null，而 map() 内部已自动处理了空值跳过。
容易忽略的关键点：
-
map()接收的函数本身不能返回null，否则整个链会变成空Optional—— 比如Person::getUsername如果返回null，那后续map就不会执行 - 若某步逻辑需区分“字段为 null”和“对象为 null”，
map()无法满足，得拆成flatMap()或显式判空 - 过度嵌套（超过 3 层
map）可读性骤降，此时不如分步写清楚每个环节的 fallback 行为
真正难缠的空指针，往往不在语法糖里，而在你没意识到某个 getter 其实会返回 null —— Optional 治标，契约约定（比如文档/注解标明非空）才治本。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
