--patch-module不能替换模块内变量定义，仅能覆盖已编译类字节码；动态变量控制应通过依赖注入、系统属性、测试配置或构建插值实现。
不能用 --patch-module 指令动态替换模块内变量定义。
这个指令的作用范围有限
--patch-module 是 Java 9+ 引入的 JVM 启动参数，用于在运行时将指定目录或 JAR 中的类文件“打补丁”进某个命名模块，从而覆盖模块原有的 class 文件。它只影响 已编译的类字节码，不处理源码级的变量定义、常量值或配置逻辑。
例如：
- 你可以用它把修改后的
com.example.MyService.class补丁进com.example.app模块，替换原实现； - 但你不能用它把
public static final String API_URL = "https://dev.api"这样的变量值，在测试时临时改成"https://test.api"—— 因为这属于编译期常量或运行时初始化逻辑，不是可被 class 替换直接改变的行为。
测试中真正可行的变量替换方式
若目标是在测试中动态控制模块行为（如切换环境、模拟配置），应采用以下更可靠、更符合测试设计原则的方法：
-
依赖注入 + 测试专用配置：在模块中避免硬编码变量，改用接口抽象（如
ConfigProvider），测试时注入返回测试值的 mock 实现； -
系统属性或环境变量：启动测试 JVM 时加
-Dmy.env=test或env=TEST，代码中通过System.getProperty("my.env")或System.getenv("env")读取并分支； - 测试专用的 @TestConfiguration（Spring）或 @QuarkusTestResource（Quarkus）：覆盖生产配置 bean，提供测试所需的变量值；
-
构建时变量插值（Maven/Gradle）：在
src/test/resources/application-test.properties中定义变量，配合资源过滤机制注入实际值。
为什么不要尝试用 --patch-module 做变量替换
即使你反编译类、修改字段值、重新打包成 class 并 patch 进去，也会遇到：
- final 字段在字节码层面被内联优化，JVM 可能根本不读取其运行时值；
- 静态初始化块（
static{}）已在类加载时执行完毕，补丁无法重放； - 模块封装限制（
--add-opens也救不了字段访问，更别说改值）； - 测试可维护性极差：补丁逻辑散落在构建脚本和二进制文件中，无法被 IDE 索引、无法调试、难以复现。
真正需要动态变量控制的场景，应该从设计上解耦配置与逻辑，而不是绕路操作 JVM 底层机制。
