工具类方法适合用optional包装，因其能显式表达“可能为空”的合法业务分支，避免null误判或异常滥用；应仅封装解析失败、查询未命中等合理为空场景，而非非法参数或系统错误。
用 Optional 封装工具类中可能返回 null 的方法，核心不是“加一层 Optional”，而是通过明确的空值语义，把“调用方是否要处理空结果”这个责任前置到 API 设计层面。
为什么工具类方法适合用 Optional 包装？
工具类（如 DateUtils、JsonUtils、StringUtils）常有这类方法：
– 解析字符串为日期（格式不对 → null）
– 从 JSON 字符串提取某个字段（路径不存在 → null）
– 根据 key 查配置项（key 不存在 → null）
这些“失败场景”本质不是异常，而是合法的业务分支。用 null 表示，调用方极易漏判；抛异常又过度（比如查一个可选配置，不存在不该中断流程）。Optional 正好表达“可能没有”的契约。
封装原则：只包装“合理可能为空”的返回值
不是所有 null 都该包 —— 重点看语义：
– ✅ 合理为空：解析失败、查询未命中、字段可选
– ❌ 不该包：参数非法（应抛 IllegalArgumentException）、系统级错误（如 IO 异常）、内部逻辑 bug（应修复）
示例（改进前后的对比）：
// 改进前：调用方容易 NPE
public static Date parseDate(String dateStr) {
try { return sdf.parse(dateStr); }
catch (ParseException e) { return null; }
}
// 改进后：契约清晰，调用方必须面对“无日期”的情况
public static Optional<date> parseDate(String dateStr) {
try { return Optional.of(sdf.parse(dateStr)); }
catch (ParseException e) { return Optional.empty(); }
}
</date>
调用时别写 get()！用 map/flatMap/filter 链式处理
Optional.get() 和 isPresent() + get() 组合，等于换汤不换药，没脱离 null-check 思维。真正价值在于函数式链式处理：
-
转换结果：
parseDate("2023-01-01").map(Date::toInstant).orElse(Instant.EPOCH) -
条件过滤：
getConfig("timeout").filter(v -> v > 0).orElse(30) -
组合多个 Optional：
findUser(id).flatMap(this::findProfile).map(Profile::getEmail).orElse("N/A") -
避免副作用：不要在
ifPresent里做复杂逻辑或修改外部状态，保持纯函数风格
注意边界：Optional 不能作为字段或参数类型
Optional 是消费端契约类型，不是数据载体：
– ❌ 不要定义 private Optional<string> name;</string>（序列化、判等、调试都麻烦）
– ❌ 不要写 public void process(Optional<user> user)</user>（调用方还得构造 Optional，违背本意）
– ✅ 正确姿势：方法返回 Optional，调用方按需消费；字段/参数仍用原始类型（User user），空值由调用方决定如何提供（null / Optional.empty() / 默认值）
不复杂但容易忽略：Optional 的意义不在避免 NPE，而在让“空”成为显式、可组合、可推理的一等公民。工具类加一层 Optional，是给调用方递一把带刻度的尺子，而不是贴一张“请小心 null”的警告贴纸。
