Optional仅适用于方法返回值，不可作为参数或字段使用：语义错位、API不友好、框架兼容差；Controller应直接接收普通参数并用required=false声明可选性，Service按需处理null逻辑，DAO返回原始类型由上层封装。
Optional 不适合在三层架构（Controller → Service → DAO）中跨层传递参数，它不是为参数传递设计的，而是用于明确表达“可能为空”的返回值。直接用 Optional 作为方法参数会破坏封装性、增加调用方负担，也违背其设计初衷。
为什么不该把 Optional 当作参数传递
Java 官方文档和主流实践（如 Spring、Guava）都明确建议：Optional 应仅用于返回值，而非方法参数或字段。原因包括：
- 语义错位：Optional 的核心价值是“迫使调用方显式处理空值”，但作为参数时，调用方本可直接传 null 或对象，无需包装；强制包装反而模糊意图。
-
API 不友好：接收方需频繁调用
isPresent()、orElse(null)等，代码冗长且易出错（如误用get()导致 NoSuchElementException）。 - 序列化与框架兼容问题：Spring MVC、MyBatis、Jackson 等框架对 Optional 参数支持有限或不一致，可能导致绑定失败、NPE 或静默忽略。
Controller 层：用普通参数 + 显式空检查
前端传参天然可能是 null 或缺失，Controller 应以清晰、符合 REST 规范的方式接收：
- 查询参数（@RequestParam）直接声明为 String/Long 等类型，Spring 会自动转 null；用
@RequestParam(required = false)明确可选性。 - 请求体（@RequestBody）中字段设为非必需（如 Lombok 的
@Schema(required = false)或 Jackson 的@JsonInclude(JsonInclude.Include.NON_NULL)）。 - 需要校验时，用
@Valid+ 自定义约束，而不是靠 Optional 掩盖业务逻辑。
示例：
立即学习“Java免费学习笔记（深入）”；
Controller@GetMapping("/users")
public List<User> getUsers(
@RequestParam(required = false) String name,
@RequestParam(required = false) Long deptId) {
return userService.findUsers(name, deptId); // 直接传 null
}
Service 层：按需封装可选逻辑，不暴露 Optional
Service 是业务编排层，应隐藏数据可选性细节，对 null 做合理默认处理或抛业务异常：
- 若参数为 null 表示“不限制”，则直接参与查询条件构建（如 MyBatis 的
<if test="name != null">）。 - 若 null 表示“非法输入”，应统一抛
IllegalArgumentException或自定义业务异常（如InvalidParamException），由全局异常处理器转化 HTTP 状态码。 - 只有当方法**返回结果可能为空**且调用方需区分“没找到”和“查出 null”时，才用 Optional 作为返回值（如
Optional<user> findById(Long id)</user>）。
DAO 层：让持久层专注数据操作，交由上层处理可选性
DAO（或 Mapper）应返回原始类型或集合，由 Service 决定如何解释结果：
- 单条记录查询返回
User，查不到时返回 null —— Service 可选择包装成Optional.ofNullable(user)再返回给上层。 - 列表查询始终返回
List<User>（空集合而非 null），这是最安全、最符合直觉的做法。 - 避免在 XML Mapper 或 Repository 方法签名中使用 Optional 参数或返回值（JPA 的
Optional<T> findById(...)是特例，因其封装了底层 null 判断，且只用于主键精确查询）。
