java类加载机制是字节码增强的唯一入口，增强必须依托加载阶段在defineclass()前修改byte[]，依赖双亲委派决定作用域，并受jpms模块约束，典型方式为javaagent注册transformer。
Java 中类加载机制与字节码增强技术的结合，本质是利用类加载过程中的“可干预节点”，在字节码进入 JVM 之前或刚加载时对其进行修改，从而实现无源码侵入的功能增强。这种结合不是并列关系，而是依赖关系——字节码增强必须依托类加载机制才能落地。
类加载阶段是字节码增强的唯一入口
JVM 加载一个类时，会经历“加载 → 验证 → 准备 → 解析 → 初始化”五个阶段。其中，加载阶段是唯一能拿到原始字节码（byte[]）并允许替换的时机。此时类尚未被验证、未生成运行时数据结构，修改字节码既安全又有效。
- ClassLoader 的
defineClass()方法执行前，字节码以二进制流形式存在，正是 ASM/Javassist/ByteBuddy 等工具的操作对象 -
javaagent 的
ClassFileTransformer.transform()回调，就是在类被defineClass()之前触发的，属于加载阶段的钩子 - 自定义 ClassLoader 重写
findClass()，可在读取字节码后、调用defineClass()前插入增强逻辑
双亲委派模型决定了增强作用域
增强是否生效，取决于哪个类加载器负责加载目标类，以及增强逻辑注册在哪个层级。不是所有类都能被任意增强。
- Bootstrap 类加载器加载的核心类（如
java.lang.String）无法被普通 javaagent 修改，因为 agent 的 ClassLoader 是 Application ClassLoader，无法委托给它自己去加载核心类 - 若想增强某个模块内的类，需确保 agent 的 transform 逻辑在该模块类被其对应模块类加载器（如 LayeredModuleClassLoader）加载前已注册
- 打破双亲委派的自定义加载器，可绕过父加载器直接增强特定路径下的类，但需谨慎处理类可见性与冲突
模块化（JPMS）带来新的增强约束
Java 9+ 的模块系统改变了类加载边界，也影响字节码增强的可行性。
- 模块未
opens的包，即使使用反射或字节码工具也无法访问其私有成员——增强后的方法若试图访问非开放包内的字段，会在链接阶段失败 - 增强逻辑自身若需跨模块调用（如注入日志工具类），必须在
module-info.java中声明requires，否则运行时报NoClassDefFoundError - 服务提供者机制（
provides ... with）可配合增强实现动态能力注册，例如在运行时为某模块注入新服务实现
典型结合方式：javaagent + 类加载拦截
这是生产环境最常用、最稳定的结合模式，完全依赖标准类加载流程，无需修改应用代码。
- 启动时通过
-javaagent:xxx.jar注册 agent，JVM 会调用其中的premain() -
premain()内调用Instrumentation.addTransformer()，注册字节码转换器 - JVM 每次准备加载类时，都会把字节码传给 transformer，开发者可基于类名、注解、方法签名等条件决定是否增强
- 增强后的 byte[] 被直接交给原 ClassLoader 的
defineClass()，后续流程不受影响
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
