optional 是显式表达“值可能为空”的类型契约，强制用于 api 层返回值（如数据库单查、缓存读取），链式取值须用 map+orelse，禁作参数/字段/集合元素/序列化载体，并按业务意图统一空值处理策略。
在企业级开发中，Optional 不是用来消灭 null，而是把“值可能为空”这个事实从隐式约定变成显式类型契约。规范判空标准的核心，是统一团队对“何时用、怎么用、严禁怎么用”的认知，避免写成更难懂的“套娃式 Optional”。
明确哪些场景必须用 Optional 封装返回值
对外暴露的 API 层（如 Controller、FeignClient、Service 接口）中，当方法语义上“结果可能不存在”，且调用方需要区分“查无此数据”和“系统异常”时，应强制返回 Optional
- 数据库单条查询（如
User findById(Long id)→ 改为Optional<user> findById(Long id)</user>） - 缓存读取（如
Optional<config> getConfig(String key)</config>） - 第三方接口响应解析后不确定是否含业务数据时
这样调用方必须显式处理“有/无”，无法忽略空场景，也避免了用 null 表达业务缺失带来的歧义。
链式取值统一用 map + orElse 系列，禁用嵌套 if
多层对象取值（如 order.getUser().getAddress().getCity()）必须重构为：
-
Optional.ofNullable(order)起始，每层用.map(…)安全穿透 - 末尾用
.orElse("默认值")或.orElseGet(() -> computeDefault())统一兜底 - 禁止出现
if (order != null && order.getUser() != null && ...)形式
示例：
String city = Optional.ofNullable(order).map(Order::getUser)
.map(User::getAddress)
.map(Address::getCity)
.orElse("未知城市");
禁止作为参数、字段、集合元素或序列化载体
这是企业代码审查的重点红线：
- 方法参数不接受
Optional<string> name</string>—— 它不是“可选参数”的语法糖，而是“返回值存在性”的契约 - 实体类字段不声明为
private Optional<string> phone;</string>—— 破坏 JavaBean 规范，影响 ORM、JSON 序列化（Jackson 默认不支持）、Lombok 等工具 - DTO 或 RPC 响应体中不包含 Optional —— 序列化会失败或行为不可控（因 Optional 不实现
Serializable） - 集合不存 Optional（如
List<optional>></optional>）—— 语义混乱，增加理解与维护成本
统一空值处理策略与异常语义
在关键业务路径上，空值不应静默兜底，而要匹配业务意图：
- 用户登录态校验失败 →
Optional.ofNullable(user).orElseThrow(() -> new BusinessException("未找到有效用户")) - 配置项缺失且不可降级 →
.orElseThrow(ConfigMissingException::new) - 前端展示字段，允许缺省 →
.orElse("暂无")或.map(...).orElse(null)（返回 null 给前端，由前端处理）
所有自定义异常需继承统一基类（如 BizException），确保全局异常处理器能识别并返回标准错误码。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
