Result包装类必须包含code（整型错误码）、message（脱敏提示）、data（泛型业务数据）；建议增加timestamp和requestId；禁用success布尔字段和模糊details；code用enum定义，Spring Boot用@ControllerAdvice分层捕获异常；泛型擦除问题推荐前端按文档二次解析；HTTP状态码优先于code，二者职责分离。
Java中Result包装类该包含哪些字段才不踩坑
统一响应结构的核心不是“看起来整齐”，而是让前端能稳定解析、后端能快速定位问题。字段少容易漏信息，字段多又导致冗余或语义混乱。
必须有的三个字段：code（整型错误码）、message（用户/调试用的提示）、data（泛型，成功时返回业务数据，失败时为null）。
可选但强烈建议加的字段：timestamp（毫秒时间戳，排查异步或重放问题时关键）、requestId（链路追踪ID，和日志/监控对齐）。
不要加的字段：success布尔字段——它和code重复，且容易被前端双重判断导致逻辑错乱；details这种模糊嵌套对象——除非有明确、结构化、可序列化的错误上下文（比如表单校验字段列表），否则一律走message + 日志。
立即学习“Java免费学习笔记（深入）”；
-
code必须是整型，别用字符串——前端 switch 判断、HTTP状态码映射、监控告警规则都依赖数值连续性和可比较性 -
message不能直接抛出异常堆栈或内部字段名（如“username is null”），要脱敏并面向用户/测试人员（如“用户名不能为空”） -
data类型必须是T，别写死成Object——否则泛型擦除后前端无法可靠反序列化
错误码字典用interface还是enum？Spring Boot里怎么注册全局异常处理器
用enum，别用interface常量接口。前者可枚举、可自带描述、可序列化、IDE能自动补全；后者只是命名空间污染，还容易被误实现或覆盖。
定义示例：
public enum ErrorCode {
SUCCESS(0, "操作成功"),
PARAM_ERROR(1001, "参数格式错误"),
NOT_FOUND(404, "资源不存在"),
SYSTEM_ERROR(500, "系统繁忙，请稍后再试");
private final int code;
private final String message;
// 构造 + getter 略
}
Spring Boot里配全局异常处理器，核心是@ControllerAdvice + @ExceptionHandler，但要注意两点：
- 别只捕获
Exception——会吞掉RuntimeException以外的底层异常（比如IOException），应分层捕获：BindException、ValidationException、BusinessException（你自定义的业务异常）等 - 别在处理器里手动new
Result——统一用静态工厂方法，比如Result.fail(ErrorCode.PARAM_ERROR)，避免构造逻辑散落 - HTTP状态码别硬编码——
ErrorCode里可加HttpStatus字段，或用@ResponseStatus注解在自定义异常上
Result泛型擦除导致前端收不到data类型怎么办
这是Jackson反序列化时最常踩的坑：后端返回Result<user></user>，前端收到的却是Result<object></object>，字段全变成LinkedHashMap。
根本原因：Java泛型运行时擦除，Jackson默认不知道你期望的T具体是什么类型。
解法只有两个，且必须二选一：
- 后端返回时显式传入泛型类型引用：
return ResponseEntity.ok().body(new Result(ErrorCode.SUCCESS, user));——前提是Result构造函数里把T存下来，并在Jackson序列化时用@JsonTypeInfo等标注（较重） - 更推荐：前端按约定处理——所有API统一返回
Result，data字段永远是JSON Object或Array，前端自己按接口文档做二次解析（比如调用userApi.login()后，手动response.data as User） - 绝对别做：在
Result里加Class<t></t>字段并试图序列化它——既破坏DTO纯洁性，又引入类型安全风险
Result包装和HTTP状态码冲突时以谁为准
以HTTP状态码为准，code字段只用于业务逻辑分流。
比如用户未登录，应该返回HTTP 401 + code=401 + message="请先登录"；而不是HTTP 200 + code=401。前者能让网关、CDN、前端axios拦截器天然识别，后者得每处都手动判断code。
常见混淆点：
- Spring Boot默认把
ResponseEntity.status(HttpStatus.UNAUTHORIZED).body(result)发出去，没问题；但有人用@ResponseBody返回Result，再靠Filter改状态码——这违反责任分离，Filter不该决定业务语义 - 微服务间调用可以弱化HTTP状态码（比如全部用200），但对外API必须严格对齐RFC规范，否则前端同学会疯
-
code=0不代表HTTP 200——它只是“业务成功”，而HTTP状态码反映的是传输/协议/权限层结果，两者维度不同，不能混为一谈
真正难的不是设计Result类，而是让所有人（前端、测试、运维、新来的后端）一致理解：code是给业务代码分支用的，HTTP status是给网络基础设施用的。这两个东西长期共存，但永远不该互相替代。
