验证APT处理器正确性的核心是用javac命令行或compile-testing库，在编译期检查其是否准确识别注解、解析元素并生成代码或报错，不依赖运行时反射，需端到端验证生成代码的可编译与可引用性。
测试编译期注解处理器（APT）的正确性，核心是验证它是否在 javac 编译阶段 准确识别目标注解、正确解析元素结构，并生成预期代码或报出合理错误。它不依赖运行时，也不靠反射——所以不能用 JUnit 启动 Spring 或调用 getAnnotation() 来测。
用 javac 命令行直接触发处理流程
这是最贴近真实编译环境的测试方式，能暴露处理器对 AST 解析、类型推导、错误报告等底层行为的真实表现：
- 准备一个含自定义注解的 Java 源文件（如
User.java），并确保该注解的@Retention是SOURCE或CLASS（编译期处理不关心 RUNTIME） - 执行带处理器的编译命令：
javac -processor com.example.MyProcessor -proc:only User.java
加-proc:only表示只做注解处理，不生成 class 文件，适合快速验证逻辑 - 观察输出：成功应生成目标文件（如
UserLog.java）或打印processingEnv.getMessager().printMessage()的提示；失败则看是否按预期抛出error级别消息（比如参数为空时报错，而非静默忽略）
用 Compile Testing 库做隔离化单元测试
推荐使用 Google 的 compile-testing 库，它在内存中模拟完整 javac 流程，支持断言生成文件内容、检查诊断信息（warning/error）、甚至验证未生成多余类：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 写测试时传入源码字符串而非真实文件，避免路径污染
- 用
assertCompilesWithoutError()验证合法用法不报错 - 用
assertCompileFailsWithMessages()断言非法用法（如注解用在字段上但@Target只允许方法）必须触发指定错误消息 - 用
generatedFile()获取生成的 .java 内容，校验包名、类名、方法签名是否完全匹配预期
检查生成代码能否被正常编译和引用
注解处理器的价值最终落在生成的代码是否可用。这步是端到端验证的关键：
立即学习“Java免费学习笔记（深入）”；
- 让处理器生成一个带 public 方法的辅助类（如
User$$Mapper） - 再写一个新类（如
TestClient），在其中 new 这个生成类或调用其方法 - 用 javac 一次性编译原始源码 + 生成源码 + 测试类：
javac -processor com.example.MyProcessor *.java - 若编译通过且
TestClient能成功调用生成类，则说明处理器产出的代码语法正确、符号可见、无命名冲突
注意避开常见误判点
很多“看似生效”的现象其实掩盖了问题：
- 不要在 IDE 里仅靠“没红叉”判断——IDE 的增量编译和缓存可能跳过处理器，务必用命令行 javac 复现
- 不要把
@Generated注解出现在 class 文件里当成处理器工作正常——那是字节码层面的事，而 APT 处理的是源码层 - 如果处理器依赖泛型类型（如
T extends Serializable），要专门构造含复杂泛型的测试用例，因为 APT 在编译期看到的是擦除后的类型，容易误判
