不能真正修改编译期常量字段：因编译器内联使其运行时不存在；jdk9+模块化与jvm写屏障禁止static final反射写入；非static final虽可临时覆盖，但受jit优化和jmm可见性限制。
不能真正“修改”被 final 修饰的编译期常量字段，不是反射用得不对，而是 JVM 在多个层面主动拦截了这种操作——从编译器优化到类加载机制，再到运行时内存模型，层层设防。
编译期常量折叠：值根本不在运行时存在
当一个字段同时满足 static final + 编译期可确定的字面量值（如 public static final int PORT = 8080; 或 static final String MSG = "OK";），Javac 就会把它“内联”掉：
- 所有对该字段的引用，在字节码里直接替换成字面量，比如
System.out.println(PORT)编译后变成iconst_8080指令； - 运行时根本不会去读取这个字段的内存地址，也就没有“修改目标”；
- 即使你用反射成功改了字段底层值，
PORT在代码中仍显示为 8080，因为那根本不是变量访问，而是硬编码。
类加载与初始化阶段：final 字段被写保护锁定
JVM 在类加载的 准备阶段 分配内存并设默认值，在 初始化阶段 执行 <clinit></clinit> 方法完成 final 字段赋值。此后：
- 对于 static final 字段，JDK 9+ 模块系统默认禁止反射写入，调用
set()会直接抛IllegalAccessException； - 即使绕过模块限制（如用
--add-opens），JVM 内部仍会对 final 字段做写屏障校验，部分版本（如 JDK 17）会拒绝修改并静默失败； - 非 static 的 final 实例字段虽可在对象构造完成后临时覆盖，但 JIT 编译器可能已将其值常量化、缓存或内联，导致后续读取仍是旧值。
Java 内存模型（JMM）的可见性陷阱
final 字段在 JMM 中享有特殊语义保障：构造器内对 final 域的写入，对其他线程首次读取该对象引用时是“保证可见”的。但反射修改破坏了这一契约：
- 修改发生在对象构造完成之后，不触发 final 域的“安全发布”机制；
- 没有 happens-before 关系，其他线程可能永远看不到新值，或看到部分更新（尤其字段是引用类型且对象内容也被修改时）；
- 如果字段是基本类型（如
int），JIT 可能将其提升为寄存器常量，反射写入仅影响堆内存，而读取走的是寄存器副本。
为什么“清除 modifiers 中的 FINAL 位”有时看似成功？
有些示例代码通过反射修改 Field.modifiers 字段来移除 FINAL 标志，再调用 set()：
- 这本质上是在欺骗 JVM 的字段访问检查逻辑，并未解除 JVM 对 final 语义的底层约束；
- 它只对非编译期常量、非 static、且未被 JIT 优化掉读取路径的字段有短暂效果；
- 在 JDK 12+ 中，
modifiers字段本身被标记为final，甚至无法通过反射修改；某些版本强制要求配合Unsafe.putObject或VarHandle才能落地。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
