IntelliJ IDEA 默认只能识别标准输出路径（如 `target/generated-sources`）下由注解处理器生成的源代码；如果采用 AST 修改等非标准技术（例如 Lombok 的字节码或编译期增强），IDE 无法自动感知这些生成的方法，需要手动配置或改用兼容的方案。
先给出一个核心判断：IntelliJ IDEA 的代码智能感知功能，本质上是基于源码文件来工作的。它只认可那些写入磁盘且路径符合规范的 `.java` 文件，对于 AST 修改这类在运行时或编译期进行的字节码魔术，它天然“看不见”。这也解释了为什么使用 Lombok 时必须先安装插件——IDE 需要额外的“翻译器”才能理解那些魔法。
在多模块 Maven 项目（比如一个 App 主模块调用了 Mods 模块中的自定义注解处理器）中，只要处理器遵循 JSR-269 标准，通过 ProcessingEnvironment.getFiler() 来生成源码文件，IDEA 是完全原生支持的，不需要额外配置。
正确做法（推荐）
- 确保注解处理器将生成的 Java 类写入标准输出路径。在 Maven 中是
target/generated-sources/annotations，Gradle 下类似——这是后续所有配置的基础。 - 在 App 模块的
pom.xml中启用注解处理，并将 Mods 声明为annotationProcessor依赖：org.apache.maven.plugins maven-compiler-plugin 3.11.0 17 17 com.example mods 1.0 - 在 IDEA 中执行最后一步：
右键target/generated-sources/annotations→ Mark as Generated Sources Root；
进入 Settings → Build → Compiler → Annotation Processors，勾选 Enable annotation processing 和 Obtain processors from project classpath；
最后 Build → Rebuild Project 触发处理器并刷新索引。
但是，如果你不走“寻常路”呢？
有些方案确实更灵活，比如用 Javassist 或 Byte Buddy 直接在字节码层面插桩，或者像 Lombok 那样在编译期修改 AST。这些做法的本质不是生成源码，而是修改编译结果。IDEA 的智能感知基于静态源码分析，它只能解析 `.java` 文件，无法‘看见’那些只存在于内存中的字节码改动。因此，这种情况下 IDE 报红是正常的，并不影响实际的编译与运行——当然，写代码时满屏红线确实让人困扰。
一些值得警惕的“野路子”：手动在同一个包下写一个一模一样的 stub 类来欺骗 IDE？短期内有效，但长期维护时 stub 与真实类不同步，隐患极大。修改 IDEA 内部 API？不仅脆弱，还会破坏团队协作的一致性。
如果确实需要 IDE 提供完整的代码补全和引用导航，替代方案是有的：
改用标准的源码生成（输出 `.java` 文件并加上 `@Generated` 注解），或者，如果你一定要用 Lombok，那就老老实实安装 Lombok Plugin——这是官方支持的插件，稳定可靠。
至此答案已经很清晰了：IntelliJ 的智能感知就是“源码洁癖”。想让 IDE 认识你生成的那些方法，请坚持 JSR-269 标准——让注解处理器输出真正的 `.java` 文件，并放在约定的路径下。非标准的 AST 增强虽然灵活高效，但这个局限，你需要自行承担。
