框架用字节码增强而非改源码，是因为运行时源码已编译为.class文件，需在不修改用户代码前提下动态插入逻辑；字节码增强可在类加载时操作二进制流，成本低、侵入小、符合开闭原则。
为什么框架要用字节码增强，而不是直接改源码
因为源码在运行时已经编译成 .class 文件，而框架（比如 Spring AOP、MyBatis、Lombok）需要在不修改用户代码的前提下，动态插入逻辑——比如加日志、事务、代理。改源码做不到热插拔，也违背“开闭原则”。字节码增强是在 JVM 加载类之前或加载时，直接操作二进制字节流，成本低、侵入小、生效快。
常见错误现象：NoClassDefFoundError 或 IllegalAccessError，往往是因为增强后字段/方法访问修饰符被意外改写，或父类/接口签名没对齐。
- ASM 操作的是底层指令，适合高性能、细粒度控制的场景（如 Spring 的
ConfigurationClassPostProcessor对@Configuration类的增强） - Javassist 更接近 Java 语法，适合快速原型或开发期插桩（如 Lombok 编译期生成
getter/setter） - 二者不能混用同一类：Javassist 修改过的类，再用 ASM 二次增强容易破坏常量池结构
ASM 的 ClassVisitor 和 MethodVisitor 怎么安全插入逻辑
核心是别破坏原有字节码结构：方法体长度、局部变量表槽位、栈深度都得对得上。很多空指针或 VerifyError 就是因为插入代码后没调用 visitMaxs 或栈平衡出错。
典型使用场景：给所有 public void save() 方法开头自动加 log.info("saving...")。
立即学习“Java免费学习笔记（深入）”；
- 必须在
visitCode()后立即插入日志调用，再调用super.visitCode()，否则会覆盖原方法入口 - 调用
log.info前，要先用visitFieldInsn(GETSTATIC, ...)把Logger静态字段压栈 - 插入完一定要补
visitMaxs(0, 0)—— ASM 4.0+ 不再自动计算，漏掉就抛AnalyzerException - 别在
visitEnd()里改方法，那是类结束时机，方法体已不可编辑
Javassist 的 CtMethod.insertBefore 为什么有时不生效
不是所有方法都能插：构造器、native、abstract 方法会直接抛 CannotCompileException；更隐蔽的问题是，被 final 修饰的类，其方法无法被子类重写，而 Javassist 默认走的是“继承重写”路径（除非显式设为 setBody 替换整个方法）。
常见错误现象：javassist.CannotCompileException: by java.lang.ClassNotFoundException: com.example.Xxx，本质是 CtClass 找不到依赖类，不是类路径问题，而是 ClassPool 没导入该类。
- 务必在获取
CtMethod前调用classPool.importPackage("org.slf4j")，否则insertBefore("log.info($1);")里的log无法解析 -
$1、$_这类符号只在insertBefore/insertAfter中有效，在setBody里得用完整 Java 语法 - 如果类已被 JVM 加载（比如通过
Class.forName），Javassist 默认拒绝修改，需提前调用ctClass.defrost()
生产环境做字节码增强最该盯住的三个点
不是功能跑通就行，JVM 对字节码校验越来越严，尤其在 JDK 9+ 模块化之后，稍有不慎就会触发类加载失败或 SecurityException。
- 类名必须用斜杠分隔（
java/lang/String），不是点号（java.lang.String）—— ASM 所有 API 都认斜杠，Javassist 在getDeclaredMethod里却认点号，混用必炸 - 增强后的类必须和原类有完全一致的
Signature（泛型信息），否则 Spring 泛型注入会失败，但错误堆栈里根本不会提 signature 事 - 避免在
Instrumentation.addTransformer里做耗时操作（如读配置文件、连 DB），它运行在类加载线程里，会拖慢整个应用启动，甚至引发死锁
真正难的从来不是“怎么加一行日志”，而是加完之后，类还能被其他框架正确识别、泛型还能对上、GC 还能正常回收——这些细节藏在字节码的常量池索引和属性表里，看不见，但一错就卡住整个链路。
