java中必须用final修饰常量的场景包括：类级别配置值、数学常量、枚举状态码等需编译期确定、防重赋值或参与类加载的值；static final是类常量唯一正确形式，且基本类型+static final会被内联，修改后须全量重编译。
Java里哪些地方必须用final修饰常量
不是所有“不变的值”都该用final，只有真正需要编译期确定、防止意外重赋值、或参与类加载逻辑的场景才值得加。比如类级别的配置值、数学常量、枚举状态码——这些一旦写死就不该被覆盖。
常见错误是给局部变量、方法参数无脑加final，既没实际约束力（JVM不检查），又干扰阅读。IDE提示“can be final”只是建议，不是规范。
-
static final用于类常量：必须同时有static和final，否则不是真正的“类级别常量” - 字符串字面量直接赋值时，
final String URL = "https://api.example.com"能触发字符串池优化；但若通过new String("...")构造，final就只剩语义约束 - 基本类型+
static final会被内联（inlined）：编译后调用处直接替换成字面量，所以修改后必须全量重编译，否则旧class仍用老值
为什么final修饰的引用类型对象内容还能改
很多人以为final List<string> list = new ArrayList()</string>之后就不能增删元素了——错。final只锁住“引用本身”，不锁住“对象内部状态”。list变量不能再指向另一个List，但list.add("x")完全合法。
想真正不可变，得用Collections.unmodifiableList()或ImmutableList.of()（Guava），或者选java.util.ImmutableCollections（Java 10+）。
立即学习“Java免费学习笔记（深入）”；
- 误用：
final Map<string integer> cache = new HashMap()</string>→ cache仍可put、clear - 正确姿势：
static final Map<string integer> CACHE = Map.of("a", 1, "b", 2)</string>（Java 9+，返回不可变Map） - 如果必须用
new构造再封禁，记得立刻包装：final List<string> names = Collections.unmodifiableList(new ArrayList(...))</string>
final在接口、方法、类中的副作用
接口里不能声明final字段（除非static final，但那是默认行为）；接口方法也不能final（语法错误）。而类上加final会彻底禁止继承，这在工具类（如Objects、Arrays）中合理，但在业务实体上容易导致测试困难（无法Mock子类）。
方法加final主要为了防止子类篡改关键逻辑，比如安全校验或资源清理。但现代框架（Spring AOP、Mockito）很多依赖动态代理或字节码增强，final方法会导致它们失效。
- Spring
@Transactional对final方法无效：代理对象无法覆盖该方法 - Mockito 3.x+ 默认无法mock
final类/方法，需启用mockito-inline并配置mock-maker-inline - Android R8/ProGuard 对
final类自动优化更强，但若反射访问其私有字段，可能因内联或移除出问题
替代final的更清晰表达方式
当目标是“只读语义”而非“编译强制”，用API契约比语法糖更可靠。比如返回Stream<t></t>而不是List<t></t>，天然避免修改；用record（Java 14+）代替final字段的手写类，字段自动final且构造不可变。
过度依赖final还会掩盖设计问题：比如一个本该拆成多个小常量类的巨型Constants类，加再多final也救不了可维护性。
- 优先用
record表示不可变数据载体：record Point(int x, int y) {}，所有字段隐式final - 配置项尽量走外部化（
@ConfigurationProperties或application.yml），而不是硬编码static final - 如果常量值来自运行时（如系统属性、环境变量），
final只是假安全感，实际值可能每次启动都不同
最易被忽略的一点：final字段的初始化顺序直接影响线程安全性。静态final字段在类初始化阶段完成赋值，是线程安全的；但实例final字段如果在构造器里通过非线程安全方式计算（比如调用外部服务），那“final”并不能保证发布安全。
