DAO层质量提升的关键是让“查不到”在类型上不可忽视：单对象查询返回Optional，集合查询返回空列表而非null，避免Optional嵌套和实体字段滥用Optional。
DAO层返回质量提升的关键，不是把所有字段都塞进Optional，而是让“查不到”这件事在类型上不可忽视。数据库字段本身是允许NULL的，但DAO方法的返回语义应当明确——查单条记录，天然就可能为空；查列表，应默认返回空集合而非null。
DAO方法返回值用Optional包装单对象
对 findById、findByName 等按唯一条件查询单个实体的方法，直接将返回类型定义为 Optional
- Spring Data JPA 已原生支持，如
Optional<user> findById(Long id)</user> - MyBatis + 自定义Mapper时，在XML或注解中返回
Optional<user></user>，框架会自动适配（需配置或使用较新版本） - 手写JDBC时，用
Optional.ofNullable(resultSet.getObject(...))封装结果，避免裸 null 返回
集合类返回值坚决不包装Optional
像 findAll()、findByStatus(String status) 这类返回多条记录的方法，应始终返回 ListCollections.emptyList() 或 new ArrayList()。
- 不要写
Optional<list>></list>：语义混乱，调用方要先解 Optional 再判空 List，徒增嵌套 - 空集合比 null 更安全、更符合函数式习惯，也便于后续直接 stream() 处理
- 若 DAO 层历史代码可能返回 null，可在 Service 层用
Optional.ofNullable(list).orElse(Collections.emptyList())统一兜底
嵌套字段提取用 map 链式穿透，不手动判空
当业务需要从用户取地址再取城市，传统写法层层 if 判空；用 Optional 后，可写成一行安全链式调用：
Optional<String> city = userRepo.findById(123)
.map(User::getAddress)
.map(Address::getCity);
任意一环为 null，整条链自动短路，最终得到 Optional.empty()，无需 try-catch 或 if。
- 注意：实体类中的 getAddress() 方法仍可返回 null，Optional 的价值在于把这种不确定性显式前移并集中处理
- 避免在实体类里把字段声明为
Optional<string></string>—— 违背序列化规范，也混淆了“数据存储”与“操作语义”
配置类或DTO中谨慎使用 Optional 字段
DTO 或前端传参对象里的字段，一般不建议声明为 Optional 类型。
- JSON 库（如 Jackson）对 Optional 支持不一致，容易出现序列化失败或字段丢失
- 前端无法理解 Optional，它只认 null / 值 / 缺失字段；后端应统一用 nullable 字段 + 文档说明
- 真正需要表达“该字段业务上可选”，应在接口文档、Swagger 注解或校验规则（@NotNull、@NotBlank）中体现，而非靠类型
