本文介绍如何通过 optional 结合方法引用与函数式链式调用，替代传统嵌套 null 检查，使业务逻辑更简洁、安全且可读性更强。
本文介绍如何通过 optional 结合方法引用与函数式链式调用，替代传统嵌套 null 检查，使业务逻辑更简洁、安全且可读性更强。
在 Java 8 及以上版本中，Optional<T> 是专为避免显式 null 检查而设计的容器类。它并非用来替代所有 null，而是明确表达“该值可能存在，也可能不存在”这一语义，从而将空值处理从防御式编码（if (x != null)）转向声明式、不可变的函数式风格。
以原始代码为例，selectById 方法返回 null 表示未查到记录，而调用方需多次重复 != null 判断（包括 DAO 调用结果和其内部字段），极易引发 NullPointerException 或逻辑冗余。优化核心在于两点：
- DAO 层统一返回 Optional<UserLog>，消除 null 返回值；
- 业务层使用 map() + ifPresent() 链式调用，将条件判断与副作用（如日志）解耦。
以下是重构后的关键代码：
// ✅ 改造 DAO 方法：明确语义，杜绝 null 返回
public Optional<UserLog> selectById(String userid) throws DataException {
List<UserLog> logs = selectUserLogs(SQL_SELECT_BY_ID, userid);
return logs.isEmpty() ? Optional.empty() : Optional.of(logs.get(0));
}
// ✅ 改造业务逻辑：用函数式链替代嵌套 null 检查
public void callingMethod() {
if (starttime != null && FIVE_HOUR <= durationSinceStartTime()) {
userLogDao.selectById(userid)
.map(UserLog::getStartTime) // 若 Optional 有值，则提取 startTime；否则短路返回 empty
.ifPresent(startTime -> log.warn("Logs came in late")); // 仅当 startTime 非 null 时执行
}
}⚠️ 注意事项：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
- 不要滥用 Optional.get() —— 它会抛出 NoSuchElementException，违背 Optional 设计初衷；应优先使用 map()/flatMap()/filter()/ifPresent()/orElse() 等安全操作。
- Optional 不应作为方法参数或字段类型（JDK 官方不推荐），仅用于返回值场景。
- 若 getStartTime() 本身可能返回 null（例如数据库字段允许为空），上述 map(UserLog::getStartTime) 会产生 Optional<null>，此时需额外 filter(Objects::nonNull) 或改用 flatMap 组合处理。
✅ 进阶建议：若需更复杂的条件组合（如同时检查 startTime 和 durationSinceStartTime()），可结合 Optional 与 Predicate 封装可复用逻辑：
private boolean isLateLog(UserLog log) {
return log.getStartTime() != null &&
Duration.between(log.getStartTime(), Instant.now()).toHours() >= 5;
}
// 使用方式
userLogDao.selectById(userid)
.filter(this::isLateLog)
.ifPresent(log -> log.warn("Logs came in late"));通过这种方式，空值校验不再是散落在各处的 if 语句，而是内聚于数据流中，既提升了代码健壮性，也显著增强了可维护性与可测试性。
