RESTful API 中应使用 Optional.ofNullable().orElseThrow() 处理“本应存在却缺失”的业务空值，配合 @RestControllerAdvice 统一返回标准错误响应，避免 null 或默认值；非业务空场景（如分页无数据）应返回 200 空列表。
在 RESTful API 开发中，当请求参数、路径变量或数据库查询结果为空时，直接抛出异常并统一返回标准错误响应，比返回 null 或默认值更符合契约精神。Java 8 引入的 Optional 配合 orElseThrow()，正是实现这一目标的简洁利器——它让“空值即异常”的语义一目了然，同时天然契合 Spring Boot 的全局异常处理机制。
用 orElseThrow 替代 if-null-throw 手动校验
传统写法需显式判空再抛异常，冗长且易遗漏：
if (user == null) {
throw new UserNotFoundException("用户不存在，ID：" + userId);
}
使用 Optional.ofNullable(user).orElseThrow(...) 一行替代，语义清晰、不可绕过：
User user = Optional.ofNullable(userRepository.findById(userId))
.orElseThrow(() -> new UserNotFoundException("用户不存在，ID：" + userId));
注意：务必用 ofNullable 包装可能为 null 的对象，避免 of(null) 抛出 NullPointerException。
与 Spring @RestControllerAdvice 联动返回标准 JSON 错误体
定义自定义异常（如 UserNotFoundException）并继承 RuntimeException，然后在全局异常处理器中统一映射：
- 标注
@ResponseStatus(HttpStatus.NOT_FOUND)，自动设置 HTTP 状态码 - 在
@ExceptionHandler方法中构造符合 REST 规范的错误响应体（含 timestamp、path、message、error） -
orElseThrow抛出的异常会被该处理器精准捕获，无需额外 try-catch
这样前端收到的是结构一致的 404 响应，而非 500 或空体，真正实现“异常即资源不存在”的语义表达。
慎用于非业务空场景：避免滥用导致误判
orElseThrow 适合明确表示“本应存在却缺失”的业务语义，但不适用于以下情况：
- 查询条件本身合法但无匹配数据（如分页查不到记录）——应返回空列表 + 200，而非 404
- 可选字段为 null 是正常状态（如用户未填“个人简介”）——不应触发异常
- 第三方服务调用返回 null 属于预期失败分支——建议用 Result 封装，而非强转 Optional
关键判断标准：这个 null 是否违反了当前接口的资源契约？如果是，才用 orElseThrow；否则应走正常控制流。
链式调用中保持异常上下文不丢失
当嵌套调用（如查用户 → 查其部门 → 查部门负责人）时，逐层使用 orElseThrow 可保留完整路径信息：
User owner = Optional.ofNullable(user)
.map(User::getDepartment)
.map(Department::getOwner)
.orElseThrow(() -> new BusinessException("用户部门或负责人信息不完整"));
若需更精确提示（如区分是部门为空还是负责人为空），可拆分为多步，每步独立 orElseThrow 并携带上下文描述，便于定位和日志追踪。
