反射不能真正修改final字段：编译期常量被内联导致无内存目标；static final在JDK9+被模块系统和写屏障拦截；非static final虽可临时写入，但受JIT优化和JMM可见性限制，读取未必生效。
反射不能真正“修改”被 final 修饰的字段，不是因为代码写得不够狠，而是 JVM 在编译、加载、运行三个阶段层层设防——常量池内联、类初始化锁死、JIT 优化屏蔽，共同让所谓“修改”变成一场对内存地址的徒劳试探。
编译期常量：值根本不在内存里
当字段同时满足 static final + 编译期可确定的字面量（如 public static final String MSG = "OK"; 或 static final int CODE = 200;），javac 会直接做常量折叠：
- 所有对该字段的引用，在字节码中被替换成硬编码指令（比如
ldc "OK"或bipush 200）； - 运行时根本不会访问该字段所在的内存地址，也就没有“目标”可改；
- 即使你用反射强行改了底层值，
System.out.println(MSG)输出仍是"OK"，因为那不是读字段，是读常量池里的字符串常量。
static final 字段：类加载后就写保护了
JDK 9 起模块系统默认拦截反射写入，JDK 17+ 更进一步：
- 调用
field.set(null, newValue)会直接抛IllegalAccessException； - 加
--add-opens参数绕过模块检查后，JVM 内部仍触发写屏障校验，部分版本静默失败； - 试图通过反射修改
Field.modifiers字段来清除FINAL标志，在 Java 12+ 已失效，modifiers字段本身也被 JVM 锁定。
非 static final 实例字段：能“写”，但不保证“读得到”
这类字段（如构造器中赋值的 private final List data;）是唯一可能被反射临时覆盖的对象：
- 必须先调用
field.setAccessible(true)； - 需确保字段不是编译期常量（即值在运行时才确定，比如
new Random().nextInt()）； - 即使成功写入，JIT 可能在编译方法时已将旧值常量化并缓存，后续读取仍返回原值；
- 多线程下无同步保障，其他线程看到新值的概率极低，受 Java 内存模型（JMM）可见性规则限制。
引用类型 final 字段：改的是对象内容，不是引用本身
final 修饰引用类型，只锁住栈上的引用地址不变，不锁堆上对象的状态：
-
private final List<string> list = new ArrayList();</string>—— 不能把list指向另一个ArrayList，但可以调用list.add("x")修改其内部； - 这种修改不依赖反射，也不触碰 final 语义，属于合法且安全的操作；
- 若想通过反射修改该
list引用本身（比如指向一个空列表），仍受限于上述所有规则，尤其是它是否为编译期常量。
