Java Agent配合Instrumentation接口才能动态替换方法体，反射仅用于增强后逻辑的运行时适配；需启用retransform并注意类加载器隔离、泛型擦除及线程上下文污染等问题。
不能靠反射直接替换方法体，Java 的反射机制只允许读取、调用已有方法，不提供修改字节码或重写方法逻辑的能力。真正能动态替换方法逻辑的，是 Java Agent 配合 Instrumentation 接口完成的字节码增强——反射在这里仅起辅助作用，比如在拦截后读取参数、构造新对象、触发远程调用等，但它本身不参与“替换”动作。
Agent 是唯一能改方法体的入口
Java 虚拟机在类加载阶段（ClassLoader.defineClass）将字节码载入内存，之后该类结构即固化。要修改方法逻辑，必须在类定义前介入，或对已加载类发起重转换（retransform）。这只能通过 Instrumentation 实现：
-
premain 或 agentmain 中注册 ClassFileTransformer：必须调用
instrumentation.addTransformer(transformer, true)，第二个参数true表示启用重转换能力 -
显式触发重定义：对目标类调用
instrumentation.retransformClasses(targetClass)，JVM 才会重新走一遍字节码转换流程 -
核心限制：bootstrap 类（如
java.lang.String）、已被 JIT 编译优化的方法、或使用了不可重定义标志的类，无法被修改
反射在其中扮演什么角色？
反射不是用来“换掉方法”，而是用来在字节码增强后的逻辑中做运行时适配：
- 在 Byte Buddy 的
@Advice.OnMethodEnter中，用Class.forName()加载业务类，再通过getDeclaredMethod()和invoke()调用外部服务（比如查配置中心决定是否跳过校验） - 用
Field.setAccessible(true)修改私有字段值（如临时覆盖某个开关状态），配合字节码逻辑实现“条件性绕过” - 把原方法参数
@AllArguments Object[] args传给反射构造的处理器，由它决定返回 mock 值还是走真实链路
推荐组合：Byte Buddy + 条件化 Advice
多数动态修改场景不需要手写 ASM。用 Byte Buddy 定义可开关的增强逻辑更安全、易维护：
- 在
Advice类里加一个静态 volatile 开关变量，通过 JMX 或 HTTP 端点动态控制 - 用
@Advice.Origin Method method获取当前被增强的方法名，结合规则引擎判断是否执行替换逻辑 - 若需完全替换方法体（如返回固定对象），用
FixedValue.value(...)；若需保留原逻辑但前置干预，用MethodDelegation拦截并委托 - 注意类型兼容：替换返回值或入参时，确保与原方法签名一致，否则类验证失败（
VerifyError）
常见失效原因和规避方式
不是代码写了就生效，几个关键点容易漏掉：
-
类加载器隔离：Spring Boot 应用常用
LaunchedURLClassLoader，Agent 默认看不到它的类。需调用instrumentation.appendToSystemClassLoaderSearch()或显式指定搜索路径 -
泛型擦除干扰日志/判断：
List在运行时只剩List，做参数类型判断时要用ParameterizedType解析，不能只看args[i].getClass() - 线程上下文污染：在 Advice 中打印日志或调用 MDC，记得清理，否则影响后续请求的 traceId 透传
