统一错误拦截器的核心是确保所有响应遵循同一数据结构和状态码语义；Response.ok与Response.status仅设置HTTP状态码，需配合Result封装、异常处理器（如@ControllerAdvice）实现全流程标准化。
在 Java Web 开发（尤其是基于 JAX-RS 或 Spring Boot 的 REST API）中，统一错误拦截器的目标不是简单地“返回错误”，而是让所有响应——无论成功或失败——都遵循同一数据结构、状态码语义和业务约定。Response.ok 与 Response.status 本身是构建 HTTP 响应的工具，真正起作用的是你如何用它们封装标准化的响应体（如统一的 Result
明确 Response.ok 与 Response.status 的定位
它们只是构建 HTTP 状态码 + 响应体 的起点，不负责业务逻辑判断或错误分类：
-
Response.ok() 等价于
Response.status(200)，适用于“操作成功且无业务异常”的场景；它不表示“没有错误”，只表示 HTTP 层成功 - Response.status(code) 用于显式设定状态码（如 400、401、500），但必须手动 setEntity() 才能塞入结构化错误体
- 二者都不自动触发全局异常处理，也不感知业务异常类型——需配合 @ExceptionHandler 或 WriterInterceptor 使用
设计统一响应体（Result）作为载体
无论 ok 还是 status，最终都应包装成一致的 JSON 结构，例如：
{
"code": 200,
"message": "success",
"data": { ... }
}
关键点：
- code 字段建议区分 HTTP 状态码（底层协议）与业务码（如 1001 表示“用户不存在”），避免混用
- message 应面向调用方，非开发日志；生产环境禁止暴露堆栈或敏感字段
- data 在错误响应中可为 null 或空对象，但字段必须存在，保持 JSON schema 稳定
用异常处理器接管错误流（以 Spring 为例）
不要在每个 Controller 里手写 Response.status(400).entity(...).build()，而是集中拦截：
- 定义自定义异常（如 BusinessException、ValidationException）
- 用 @ControllerAdvice + @ExceptionHandler 捕获，并统一构造 Result.error(...) 封装体
- 对未捕获的 RuntimeException，兜底返回 500 + 通用错误 Result
- 注意：@ExceptionHandler 不处理 404、406 等由 Spring MVC 自动返回的状态，需额外配置 WebMvcConfigurer 或 ErrorController
Response.ok / status 该在哪里用？
仅保留在明确需要绕过默认序列化流程的少数场景：
- 文件下载接口：用 Response.ok().entity(inputStream).header("Content-Type", "...").build()
- 需精确控制缓存头、ETag 的读接口：Response.ok(entity).cacheControl(...).build()
- 兼容旧客户端要求返回纯文本或特定格式时
- 日常 JSON API 接口，直接 return Result.success(data) 即可，由 @ResponseBody 自动转 JSON + 200 状态
不复杂但容易忽略：统一拦截器的价值不在“怎么返回”，而在“所有出口都走同一套规则”。Response.ok 和 Response.status 是螺丝刀，而 Result 结构、异常分类、日志埋点、监控指标才是整套工具箱。
