Optional 应仅用于方法返回值以明确表达“可能为空”的语义，不可用于参数或字段；通过 ofNullable 和链式 map 实现安全导航，配合 ifPresent、orElseThrow 等处理分支，避免 of(null)、集合嵌套 Optional 等误用。
Optional 类不是用来包装业务逻辑的，而是用来明确表达“值可能存在，也可能不存在”这一语义。它本身不执行业务逻辑，但能让你在处理可选步骤时，把“空值防御”从层层 if 判断中解耦出来，让核心逻辑更聚焦、更安全、更易读。
明确 Optional 的适用位置：只用于返回值，不用于参数或字段
Java 官方文档强调：Optional intended to be used as a return type for methods that could return no value。也就是说，它最适合出现在方法签名的返回类型中，比如：
-
✅ 正确用法：`public Optional
findUserById(Long id)` —— 查不到用户时返回 `Optional.empty()`，而不是 `null` -
❌ 错误用法：`public void process(Optional
order)` —— 把 Optional 当参数传入，反而增加调用方负担 - ❌ 错误用法：`private Optional address;` —— 作为类字段会破坏封装性，且序列化、持久化都可能出问题
用链式调用串联多个可选步骤
当业务路径涉及多层嵌套的“可能为空”的对象（如用户 → 地址 → 城市 → 邮政编码），传统写法极易陷入箭头形嵌套。用 Optional 可以把判断和转换融合为一条清晰的数据流：
- `Optional.ofNullable(user)` 启动链条，把原始可能为 null 的输入转为可控容器
- 连续 `.map(User::getAddress).map(Address::getCity).map(City::getZipCode)` 实现安全导航——任一环节为 empty，后续 map 自动跳过，不会抛 NPE
- 结尾用 `.orElse("000000")` 或 `.orElseGet(this::getDefaultZip)` 提供兜底，语义清晰
示例代码：
String zip = Optional.ofNullable(user)
.map(User::getAddress)
.map(Address::getCity)
.map(City::getZipCode)
.filter(zip -> !zip.trim().isEmpty())
.orElse("000000");
配合 ifPresent / orElseThrow 处理分支动作
某些可选步骤需要“有值才执行某操作”，或“无值就立刻报错”，这时不用写 if 判断，直接用语义化方法：
- `optional.ifPresent(emailService::sendWelcomeEmail)` —— 仅当用户存在时发欢迎邮件，逻辑干净无副作用
- `orderItem.getDiscount().map(Discount::getValue).orElse(0.0)` —— 折扣可能为空，直接转为默认数值参与计算
- `payment.getRefundId().orElseThrow(() -> new BusinessException("退款单号缺失"))` —— 强制要求该字段必须存在，否则抛业务异常
避免常见陷阱：别为了用而用
Optional 是工具，不是装饰。滥用反而降低可读性或引入隐患：
- 不要用 `Optional.of(null)` —— 会立即抛 NPE；应始终用 `Optional.ofNullable(...)` 处理可能为 null 的来源
- 不要在集合里存 `Optional
`（如 `List >`）—— 这等于两层可选，语义混乱，通常说明设计有问题 - 不要用 Optional 包装基本类型（如 `Optional
`）做算术运算——容易因 `isPresent()` 检查遗漏导致空指针，不如用 `int` + 默认值更直接 - 数据库查询结果、RPC 返回对象等外部依赖，建议统一在 DAO 或 Client 层就转成 Optional，上层服务只面对明确的“有/无”契约
