retransformClasses仅覆盖方法体字节码，不改变Class对象身份；可安全修复空指针判断、数值计算、条件表达式等方法内逻辑，但禁止增删字段、修改方法签名或static final常量。
retransformClasses 不是“换掉一个类”，而是让 JVM 用新字节码覆盖已加载类中**方法体的运行时实现**。它不改变 Class 对象身份，也不触发类卸载或重新加载，因此能真正实现无感知热修复。但它的能力边界非常明确：只允许改方法内部逻辑，其余任何结构性改动都会失败。
哪些变量逻辑可以安全热替换
所谓“变量逻辑”，实际是指对变量的读写、判断、计算等操作——只要这些操作都封装在某个方法体内，且不依赖被禁止修改的结构要素，就可以热替换。
- 修复空指针判断遗漏：
if (user != null && user.getId() > 0)→ 补上&& user.isActive() - 修正数值计算错误：
return amount * 0.09;→ 改为return amount * 0.12;（税率调高） - 绕过临时异常分支：
if (isDebugMode) { throw new RuntimeException("mock"); }→ 直接删掉该 if 块 - 调整条件表达式中的变量引用：
if (order.getTimeout() < 3000)→ 改为< 5000（注意：不能改 static final TIMEOUT 字段本身）
哪些看似相关但实际不可行
很多开发者误以为“改变量”就是改字段，但 retransformClasses 完全不支持运行时变更类结构。以下操作会直接抛 UnsupportedOperationException 或导致 VerifyError：
- 新增一个
private String traceId;字段用于日志追踪 - 把
private int retryCount = 3;改成= 5;（字段初始值属于类结构，不可重转换） - 将
static final int MAX_RETRY = 3;改为= 5;（JVM 已内联，新值不会生效） - 在方法里新增局部变量声明后，未同步更新局部变量表长度（ASM 编写时常见校验失败原因）
验证与落地的关键检查点
不靠猜测，靠实测。每次热替换前必须确认三件事：
- 目标类是否可重转换：
inst.isModifiableClass(OrderService.class)返回 true 才继续 - 字节码是否由当前 ClassLoader 加载：
OrderService.class.getClassLoader()必须和你编译修复类时使用的 classpath 环境一致 - 是否命中原始类而非代理类：Spring 的
OrderService$$EnhancerBySpringCGLIB$$xxx不可重转换，必须对OrderService本身操作；可用sc -d *OrderService在 Arthas 中确认
推荐做法：用 Arthas 封装链路，避开手工陷阱
直接调用 retransformClasses 容易因 ClassLoader 不匹配、字节码校验失败或 Agent 冲突而静默失败。Arthas 把复杂环节收口了：
- 用
jad --source-only com.example.OrderService反编译出可读源码 - 修改后通过
mc -d /tmp /tmp/OrderService.java编译，自动适配当前 classpath 和 JDK 版本 - 执行
retransform /tmp/com/example/OrderService.class，Arthas 自动处理 Transformer 注册、校验与回滚 - 立刻用
watch com.example.OrderService processOrder '{params, returnObj}' -n 1观察入参与返回值是否符合预期
