final不能替代常量命名规范，因仅防重赋值而不保语义清晰；真正防魔数需命名可读、作用域可控、集中可查；static final成对出现才具编译期常量语义并支持内联与注解引用。
为什么 final 不能直接替代常量命名规范
用 final 声明变量只是阻止重新赋值，不等于定义了语义清晰的常量。比如 final int TIMEOUT = 30000; 看似合理，但若散落在不同类里、没加 static、没统一管理，它还是魔数——只是“锁住的魔数”。真正防魔数的关键是：命名可读 + 作用域可控 + 集中可查。
final static 必须成对出现才具备常量语义
Java 中只有 static final（顺序无关）才能被 JVM 视为编译期常量，从而支持内联优化，也才能在接口、注解等场景被安全引用。漏掉 static 会导致每个实例都持有一份副本，且无法在 switch 表达式或注解值中使用。
-
public static final String API_VERSION = "v2";✅ 可用于@RequestMapping("/api/API_VERSION") -
public final String DB_NAME = "user_db";❌ 实例变量，不能作为注解参数；类加载时未初始化，IDE 无法可靠推导其值 -
private static final int MAX_RETRY = 3;✅ 推荐：私有 + 静态 + final + 大写下划线命名
魔数残留的三个高发场景及写法建议
业务代码里最常“假装用了常量”实则仍藏魔数的地方：
-
硬编码在 if 条件里：别写
if (status == 2)，应定义public static final int STATUS_PAID = 2;，并确保所有状态值集中在一个StatusConstants类中 -
字符串拼接路径或 SQL 片段：避免
"SELECT * FROM " + table + " WHERE type='admin'"，把'admin'换成RoleType.ADMIN.getValue()，类型安全且可检索 -
浮点容差值：如
Math.abs(a - b) ，应声明public static final double EPSILON = 1e-6;，否则多人复制粘贴时容易变成0.001或1e-5，逻辑不一致
注意 final 对引用类型只锁定地址，不锁定内容
这是最容易忽略的陷阱：final List 允许调用 NAMES.add("foo") —— final 只保证 NAMES 不会指向另一个 List 实例，但不阻止修改其内部元素。要真正不可变，得用 Collections.unmodifiableList() 或更推荐的 ImmutableList.of()（Guava）或 List.of()（Java 9+）。
所以，真正防魔数的常量，不是靠 final 锁住变量，而是靠明确的语义、集中的定义位置、不可变的数据结构，以及团队约定的检查机制（比如 SonarQube 规则禁止字面量出现在 if/case/注解中）。
