错误码应升级为结构化元数据，通过final errorcode字段、枚举统一管理、上下文参数动态填充及全局处理器标准化响应与日志。
关键在于把错误码从“字符串常量”升级为“可管理、可追溯、可扩展”的结构化元数据，而不是在 throw new RuntimeException("ERR_001") 里硬编码。
错误码必须封装进异常对象本身
不能只靠 message 字符串携带语义。自定义异常类要声明 final 的 errorCode 字段（String 或 int 类型），并在构造时赋值：
- 字段用 final 修饰，确保不可变，避免运行时被意外覆盖
- 提供 public String getErrorCode() 方法，供全局处理器、日志组件或监控系统统一提取
- 避免在每个 throw 处重复写 new BusinessException("USER_NOT_FOUND", "...")，容易漏、难检索
用枚举统一管理错误码，杜绝散落硬编码
把所有业务错误码收拢到一个枚举类中，每个枚举项自带 code、默认提示、HTTP 状态码等元信息：
- 例如 USER_NOT_FOUND("U001", "用户不存在", HttpStatus.NOT_FOUND)
- 异常类构造器直接接收枚举实例：
new BusinessException(ErrorCode.USER_NOT_FOUND) - 这样既类型安全，又支持 IDE 自动补全；改一个枚举项，全链路（日志、响应、文档）自动同步
错误码要能动态带上下文参数
纯静态消息不够用。比如“用户 {id} 不存在”比“用户不存在”更能定位问题。实现方式有两种：
- 构造异常时传参：
new BusinessException(ErrorCode.USER_NOT_FOUND, userId) - 枚举内部支持格式化：
message = String.format(defaultMessage, args) - 前端收到的 message 是填充后的结果，日志里也记录完整上下文，排查时不用再翻请求体
全局处理器中让错误码真正落地生效
抛出异常只是第一步，必须由 @ControllerAdvice 拦截并转化为标准响应：
- 响应 JSON 中必须包含 code 字段（取自 getErrorCode()），前端靠它做 switch 分支提示
- 日志记录时带上 errorCode：
log.warn("业务异常[{}], userId={}", ex.getErrorCode(), userId, ex) - 不打印堆栈给前端，但日志里保留 cause 完整链路——既能看业务含义（U001），也能顺藤摸到数据库超时等根因
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
