不能只靠 public static final int 管理状态码，因其缺乏编译期校验、耦合分散、易出错且不可枚举；推荐用 enum 实现，天然支持字段、方法、序列化与安全查找。
直接说结论：用 public static final 定义整型常量 + 配套的 Map<Integer, String> 映射表，但别把映射逻辑塞进常量类里；更推荐用 enum 替代。
为什么不能只靠 public static final int 做状态码管理
常见错误现象是定义一堆 public static final int SUCCESS = 200、ERROR = 500，然后在日志或响应体里硬写 if (code == ERROR) return "服务器错误"。问题在于：
- 状态码和描述耦合分散，改文案要翻遍所有
if分支 - 没有编译期校验——传入一个未定义的
999，运行时才出错 - 无法自动提供全部可用码列表（比如前端下拉框需要枚举）
- 多模块引用时，容易因静态导入冲突或同名常量覆盖引发编译失败
用 enum 实现带描述的状态码（推荐做法）
Java 枚举天然适合这个场景：每个枚举常量自带字段、方法，支持编译期约束，还能直接序列化为 JSON。
示例：
public enum HttpStatus {
SUCCESS(200, "操作成功"),
NOT_FOUND(404, "资源不存在"),
SERVER_ERROR(500, "系统异常");
private final int code;
private final String message;
HttpStatus(int code, String message) {
this.code = code;
this.message = message;
}
public int getCode() { return code; }
public String getMessage() { return message; }
// 可选：按 code 查找
public static HttpStatus fromCode(int code) {
for (HttpStatus s : values()) {
if (s.code == code) return s;
}
throw new IllegalArgumentException("Unknown status code: " + code);
}
}
使用时直接 HttpStatus.SUCCESS.getCode() 或 HttpStatus.NOT_FOUND.getMessage()，安全、可读、可维护。
如果必须用 public static final 类，怎么避免踩坑
某些老项目或框架约束下仍需常量类，注意以下几点：
- 常量类必须是
final class，防止被继承篡改 - 所有状态码字段必须显式初始化，否则编译报错：
The blank final field xxx may not have been initialized - 不要在常量类里初始化
Map静态字段——JVM 类加载顺序可能导致static块执行早于常量赋值，引发NullPointerException - 若需映射表，应由单独的工具类（如
StatusMapper）负责构建，且使用unmodifiableMap包裹，防止外部修改 - 命名严格遵守全大写+下划线，如
USER_NOT_FOUND = 404，否则其他开发者无法一眼识别其常量属性
接口里声明 public static final 状态码？别用了
虽然语法允许，但实际中已不推荐：
- 接口本意是契约，不是数据容器；把配置塞进去违背单一职责
- 多个接口含同名常量（如都定义
TIMEOUT），实现类会编译失败 - 常量值必须是编译期常量，无法动态加载配置中心里的状态码描述
- 现代 Spring Boot 项目更倾向用
@ConfigurationProperties或record封装结构化配置
真正容易被忽略的是：状态码的“语义一致性”比“技术实现”更重要。哪怕用了 enum，如果不同模块对 401 的解释不统一（是登录过期？还是 token 格式错误？），整个系统的错误处理链路就不可靠。定义之前，先和前后端对齐业务含义。
