dao层应直接返回optional以明确空值契约，调用方通过map/flatmap链式处理、orelse系列语义化兜底，避免get()和ispresent()冗余判断，且不应用optional包装集合。
数据库查询结果为空时，用 Optional 包装返回值不是终点，关键在于后续如何避免 get()、isPresent() 等冗余判断，真正发挥其函数式表达力。
把 Optional 当作“可能不存在的值”来设计 API
DAO 层方法直接返回 Optional<user></user>，而不是 User 或 null。这样调用方从签名就能感知空值可能性，无需查文档或看实现：
public Optional<user> findById(Long id) {
return Optional.ofNullable(jdbcTemplate.queryForObject(
"SELECT * FROM user WHERE id = ?",
new Object[]{id},
new UserRowMapper()));
}</user>注意：不要在 service 层手动包装 new Optional.ofNullable(user) —— 这违背了 Optional 的语义初衷，应由数据访问层统一承担“是否可空”的契约责任。
用 map/flatMap 链式转换，跳过空值逻辑
当需要对查询结果做后续处理（如取用户名、查关联订单），直接用 map 和 flatMap，空值自动短路，不抛异常也不需 if 判断：
-
userOpt.map(User::getName).orElse("未知用户")—— 安全取字段，默认兜底 -
userOpt.flatMap(this::findLatestOrder).map(Order::getAmount).orElse(0.0)—— 多层依赖查询，任一环节为空都自然返回默认值 -
userOpt.filter(u -> u.getStatus() == ACTIVE).map(this::sendWelcomeEmail)—— 带条件执行，空或不满足条件都不触发
配合 orElse / orElseGet / orElseThrow 做语义化兜底
根据业务场景选择合适的方法，避免生硬的 if (opt.isPresent())：
- 固定默认值 →
orElse("游客") - 兜底逻辑较重（如查缓存、发日志）→
orElseGet(() -> fetchDefaultUser())（懒执行） - 空值属于异常流程（如必须存在的配置项）→
orElseThrow(() -> new UserNotFoundException("ID: " + id))
慎用 get()，绝不用于生产逻辑分支
get() 应只出现在你 100% 确认非空的极少数场景（如单元测试断言），否则等于把 NPE 延迟到运行时。如果发现写了 if (opt.isPresent()) { opt.get() }，说明设计上可以改用 map 或 orElse 重构。
另外，不要用 Optional 包装集合（如 Optional<list>></list>）。集合本身已有空集合（emptyList()）和 null 两种状态，Optional 只会增加理解成本；该用 List.isEmpty() 或 CollectionUtils.isNotEmpty() 就够了。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
