APT仅在编译期基于源码AST生成Java文件，不操作字节码；字节码增强（如ASM/Agent）发生在类加载阶段，需依赖APT生成的元数据协同实现，二者生命周期分离、职责分明。
Java 中自定义注解处理器（APT）本身**不直接参与类加载或字节码增强**，它只在编译期工作，作用于源码层面（AST），生成新 Java 文件或修改已有结构。而字节码增强（如 CGLIB、ASM、Byte Buddy）发生在**类加载阶段或运行时**，由类加载器（ClassLoader）或 JVM Agent 触发。两者属于不同生命周期，需明确分工、协同配合才能实现“注解驱动的字节码增强”。
注解处理器负责“标记与准备”，不操作字节码
自定义 Processor（继承 AbstractProcessor）只能：
- 扫描源码中带特定注解的类/方法/字段（如
@Trace、@Retry） - 解析其结构（类型、参数、注解属性），生成辅助信息（如元数据文件、注册类、配置类）
- 不能读取或修改 .class 字节码——编译器尚未产出 class 文件，此时字节码还不存在
例如：你写 @Log 注解，Processor 可生成一个 LogConfig$$Generated.class 描述哪些方法要埋点，但不会重写目标类的字节码。
字节码增强必须交由类加载环节完成
真正修改字节码的时机有两类，均在 类被加载进 JVM 前后：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
立即学习“Java免费学习笔记（深入）”；
-
启动时增强（Java Agent）：通过
premain+Instrumentation，用 ASM/Byte Buddy 在ClassFileTransformer中拦截defineClass，对匹配类名的字节码做织入（如插入日志逻辑） -
加载时增强（自定义 ClassLoader）：覆写
findClass()或defineClass()，在从字节数组构建Class对象前，先用字节码库改写字节流（适合模块化隔离场景）
关键点：增强逻辑需根据注解处理器生成的元数据（如 JSON 配置、接口实现类）来决定增强哪些类、插入什么逻辑，而非硬编码。
典型协作流程：APT + Agent 实现闭环
以自动添加监控埋点为例：
- 步骤一：定义
@Monitor注解（@Retention(RUNTIME)） - 步骤二：编写 Processor，扫描所有
@Monitor方法，生成monitor-rules.json到META-INF/目录 - 步骤三：开发 Java Agent，在
premain中注册ClassFileTransformer - 步骤四：Agent 启动时读取
monitor-rules.json，用 Byte Buddy 匹配对应类和方法，插入计时逻辑 - 步骤五：运行时，JVM 加载类前已被增强，无需反射或代理，零运行时开销
为什么不直接在 Processor 里用 ASM？
因为 Processor 运行在 javac 编译过程中，此时只有 .java 源文件和 AST，没有 .class 文件；而 ASM 操作对象是已编译的字节码流。强行在编译期调用 ASM 会破坏编译流水线，且无法保证目标类是否已编译完成（存在依赖顺序问题）。Spring AOP 和 Lombok 都遵循这一分层原则：Lombok 改 AST，Spring AOP 用 BeanPostProcessor 创建代理，而非在编译期动字节码。
