关键在于绕过双亲委派、确保类未被提前加载，并用正确方式注入字节码：需继承ClassLoader重写findClass但避免loadClass委托，或使用MethodHandles.defineClass直接定义；Java Agent是增强第三方库的最可靠时机。
关键不在“自定义类加载器”本身，而在于绕过双亲委派、确保原始类未被提前加载，并用正确方式注入字节码后定义类。
必须避开双亲委派的默认陷阱
继承 ClassLoader 并重写 findClass 是常见做法，但容易失效——因为 loadClass 默认会先委托父加载器。只要目标类（比如 com.example.Service）已被系统类加载器或应用类加载器加载过，你的自定义逻辑就完全不会触发。
- 不要依赖
new MyClassLoader().loadClass("X")：它仍走委托链，大概率加载的是旧版本 - 真正可控的方式是让目标类**从未被任何上级加载器见过**：要么在启动前拦截（如 Java Agent），要么在隔离上下文中首次引用
- 若用于测试或热替换场景，可配合 URLClassLoader 指定独立 classpath，并显式设置父加载器为
null（禁用委托）
ASM 修改后，别用 findClass + defineClass 手动加载
很多教程教你在 findClass 里调用 defineClass，但这要求你已拿到修改后的字节码数组，且需处理常量池、签名等细节。更稳妥、更现代的做法是直接使用运行时 API：
- 用 MethodHandles.lookup().defineClass(byte[]) —— 它不经过类加载器委托，生成的类与当前模块同包、可直接 new 实例、支持反射
- 该方法返回
Class<?>，后续可直接clazz.getDeclaredConstructor().newInstance() - 注意：只能在模块有
addOpens或addReads权限时访问私有成员，否则会抛IllegalAccessException
Javassist 的加载更轻量，但仍有前提
Javassist 提供 CtClass.toClass() 方法，内部会尝试用当前线程上下文类加载器（TCCL）加载。它看似简单，但生效前提是：
立即学习“Java免费学习笔记（深入）”；
- 目标类尚未被 TCCL 加载；否则抛
LinkageError: duplicate class definition - 若需强制替换，得用 CtClass.detach() 防止缓存干扰，再调用
toClass(ClassLoader parent, Class> protectionDomain)指定新加载器实例 - 不建议在生产环境反复调用
toClass()，因 JVM 不允许重复定义同名类（除非用 Instrumentation.retransformClasses）
第三方库类（如 Spring/Log4j）也能增强，但时机很关键
它们不是不能动，而是必须在**首次加载前**介入：
- Java Agent 是最可靠方式：
premain或agentmain中注册 ClassFileTransformer，在transform回调里用 ASM/Javassist 修改字节码并返回 - 不能等 Spring 上下文启动完再去增强
BeanPostProcessor类——那时早已加载完毕，只能靠 retransform（需开启-javaagent且目标类支持） - 对于 Log4j 的 Appender，若想注入日志上下文，必须在
LoggerContext初始化前完成字节码替换，否则配置阶段就已绑定原始字节码
