使用enum管理异常码可实现类型安全、编译期校验、ide自动补全，并支持绑定http状态码、可重试性等行为；通过code键+messagesource动态解析多语言消息，避免硬编码；需正确注入messagesource并传入locale与参数，http状态码应按语义严格对齐。
为什么用 Enum 而不是 String 或常量类存异常码
直接写 "user.not.found" 或用 public static final String 管理错误码，会导致散落、难检索、易拼错。Enum 把“码”和“行为”绑定在一起，天然支持类型安全、IDE 自动补全、编译期校验——比如你写 UserError.NOT_FOUND，一旦拼成 NOT_FOUNT，编译就报错。
更重要的是，Enum 可以自带属性和方法，比如语言无关的默认消息、HTTP 状态码、是否可重试等，避免在每个抛异常的地方重复判断。
- Enum 实例是单例，无反射/构造开销，比每次 new 一个异常对象更轻量
- 不依赖 Spring 的
MessageSource也能先定义好结构，后续加国际化只是扩展字段 - 如果团队用 Protobuf 或 OpenAPI 定义错误码，Enum 名称可与协议字段严格对齐，减少映射层
如何让 Enum 支持多语言消息动态解析
关键不是把所有翻译塞进 Enum 里（那会污染业务逻辑），而是让 Enum 提供「消息键」+「占位符参数」，由 Spring 的 MessageSource 在运行时按当前 Locale 查找并填充。
示例：定义 UserError 枚举项：
立即学习“Java免费学习笔记（深入）”；
public enum UserError {
NOT_FOUND("user.not.found", HttpStatus.NOT_FOUND),
PASSWORD_EXPIRED("user.password.expired", HttpStatus.UNAUTHORIZED);
private final String code;
private final HttpStatus status;
UserError(String code, HttpStatus status) {
this.code = code;
this.status = status;
}
public String getCode() { return code; }
public HttpStatus getStatus() { return status; }
}
抛出时只传 key 和参数：
throw new InternationalizedException(UserError.NOT_FOUND.getCode(), userId);
资源文件中对应：
user.not.found=用户 {0} 不存在（exceptions_zh_CN.properties）user.not.found=User {0} not found（exceptions_en_US.properties）
- 不要在 Enum 里硬编码中文或英文字符串，否则无法热更新、无法做 A/B 测试语言策略
- 占位符统一用
{0},{1}，避免混用%s或{id}，否则MessageFormat解析会失败 - 若需动态决定语言（如 API 请求头带
Accept-Language），别用ThreadLocal手动设Locale，优先走 Spring 的LocaleResolver链路
全局异常处理器里怎么正确调用 MessageSource
很多人在 @ExceptionHandler 方法里直接 new ResourceBundleMessageSource，这是错的——它没加载配置、不支持 reload、也不走 Spring 的 bean 生命周期管理。
必须通过注入方式获取已配置好的 MessageSource bean：
@Autowired private MessageSource messageSource;
然后用它解析：
String msg = messageSource.getMessage(exception.getCode(), args, LocaleContextHolder.getLocale());
-
args是 Object[] 类型，必须和资源文件里的占位符数量、顺序一致，否则抛IllegalArgumentException - 别忽略第三个参数
Locale，不传会 fallback 到 JVM 默认 locale，导致中英文混用 - 如果项目用了多数据源或分模块部署，确认
basenames配置路径是否包含所有模块的exceptions_*.properties，漏一个就 fallback 成 key 字符串本身
Enum 异常码和 HTTP 状态码怎么对齐才不翻车
常见错误是把所有业务异常都返回 500 Internal Server Error，或者把 NOT_FOUND 错配成 400 Bad Request。状态码不是随便选的，它影响前端重试逻辑、网关路由、监控告警阈值。
建议按语义分层设计：
-
400：客户端参数明显非法（如手机号格式错、JSON 缺字段）→ 对应VALIDATION_FAILED -
401/403：鉴权失败 →UNAUTHORIZED,FORBIDDEN -
404：资源确实不存在（非空查询结果）→NOT_FOUND -
422：语义错误（如余额不足、状态不允许操作）→UNPROCESSABLE_ENTITY -
500：仅用于未捕获的系统级异常，Enum 里不该出现UNKNOWN_ERROR这种模糊码
真正容易被忽略的是：Spring Boot 默认的 ResponseEntityExceptionHandler 会拦截部分异常并覆盖你的状态码。如果你自定义了 @ResponseStatus 注解，要确认它没被更高优先级的处理器吞掉。
