error-prone

Error Prone 深度解析：把“能编译但必错”的代码拦在构建线之前

项目背景与痛点

Java 编译器是宽容的。语法对、类型对，它就放行。于是大量语义上几乎注定出错的代码会安安稳稳地通过 javac：用 == 比较两个 String、对数组调用 equals()、SimpleDateFormat 被多个线程共用、Optional.get() 前不做 isPresent() 检查、@Override 漏写导致父类方法改名后子类悄悄失效、String.format 的占位符与实际参数个数不匹配、锁在异常路径上没有释放……

这些问题有个共同点：它们不是风格问题，而是缺陷，但传统静态检查链条并不擅长处理。Checkstyle 基本只做文本与轻量 AST 层面的事，拿不到完整类型信息；PMD 的类型解析有限；SpotBugs 在字节码上工作，丢失了源码上下文，也就无法给出可读的修复建议；IDE 的 inspection 很好用，却只在开发者本地生效，CI 上拦不住。

Error Prone 的思路很直接：别在编译器外面另起一套解析器，直接住进编译器里。它把自己注册为 javac 的插件，与编译器共享同一棵 AST、同一份符号表和类型模型，于是检查可以做到"类型精确"，并且能在编译阶段就把诊断升级为错误，让构建失败——同时附带补丁，把修复也一并做了。这正是它在 Google 内部被推到几乎每个 Java 构建上的原因。

核心技术揭秘

理解 Error Prone 的关键，是它挂载的位置。早期版本通过 JavacTask.addTaskListener 以注解处理器形态寄生在编译器里，后来转向 com.sun.source.util.Plugin SPI，用 -Xplugin:ErrorProne 启动。这个位置决定了三个决定性优势：无需二次解析与 classpath 重建，冷启动开销几乎为零；天然拥有泛型推断后的类型结果与重载决议结果，误报率远低于独立 linter；并且能读到注解处理器生成的代码。

架构上最值得称道的是单遍扫描 + 匹配器分发。每个检查是一个 BugChecker 子类，通过 @BugPattern 声明名称、摘要、严重级别与解释文档。ErrorProneScanner 只遍历 AST 一次，把当前节点交给注册的 matcher 判断是否属于自己关心的形态，再分发给对应 checker。如果让几百个检查各自 TreeVisitor 全树走一遍，复杂度是 O(检查数 × 节点数)，在大型仓库上完全不可接受；单遍分发把它压回 O(节点数)。

匹配层用了一套 DSL：MethodMatcher、ConstructorMatcher、InstanceOfMatcher、AbstractReturnValueMatcher，配合 allOf / anyOf / not 组合。规则作者写的是声明式谓词，而不是手写 visitor 的样板代码——这是 Error Prone 规则数量能滚到数百条量级的工程前提。对于需要跨语句推理的检查（空指针、常量传播、资源泄漏），项目内置了基于控制流图的 dataflow 子模块，先为方法构建 CFG，再做数据流求解，NullAway 这类项目正是建立在这层之上。

修复能力由 SuggestedFix 承载：诊断可以带文本级 patch（替换、前缀、后缀）或基于语法树的替换。开启 -XepPatchChecks + -XepPatchLocation 后，它能直接产出 unified diff 批量落盘。更进一步的是 Refaster：你写出"改前"和"改后"两段普通 Java 模板代码，框架把模板编译成匹配器，让不懂编译器内部 API 的工程师也能定义语义级重构规则。这是我在同类工具里见过的最优雅的一层抽象。

功能亮点与差异

• 精度来自编译器同源信息：能正确处理泛型、重载、继承与注解处理器输出，这是文本型工具的硬伤。
• 错误即构建失败：不是"事后报告"，而是流水线上的硬闸门，配合自动补丁形成闭环。
• 规则可测试、可工程化：CompilationTestHelper 允许把内联源码片段与期望诊断写进单测，规则与测试同仓演进，适合团队自建私有规则。
• 分级与抑制机制完整：@SuppressWarnings("CheckName") 精确到行，-Xep:CheckName:OFF/WARN/ERROR 精确到检查项。

对比来看：Checkstyle 管风格、SpotBugs 管字节码模式、SonarQube 是重平台，而 Error Prone 的独特定位是编译期缺陷拦截 + 可执行修复，且深度绑定 Bazel 生态，落地路径最短。

应用场景与落地建议

适合中大型 Java 团队，尤其是多仓库微服务与 Android 工程。落地时注意几点：

1. 别一上来就开 ERROR。先用 -XepAllErrorsAsWarnings 跑一轮拿到基线，再逐条把高频、低误报的检查升为 ERROR。
2. 库存代码用补丁批处理。-XepPatchChecks 先生成 diff，人工过一遍再合，比逐条手改现实得多。
3. 小心 JDK 模块化。Error Prone 依赖 com.sun.tools.javac 内部 API，JDK 16+ 需要一堆 --add-exports / --add-opens；JDK 升级时它往往是最先炸的一环，务必锁版本并在 CI 里做灰度。
4. 注解处理器冲突。Lombok 生成的代码会让部分检查误报，需要配置排除路径；生成代码目录建议整体 -XepExcludedPaths。
5. 构建工具：Bazel 原生支持最顺；Gradle 用 net.ltgt.errorprone 插件；Maven 需手动挂 javac plugin 参数。

综合评价

优点：类型精度高、误报可控；编译期执行，几乎零额外成本；诊断与修复一体；规则体系工程化程度罕见；有 Google 超大规模仓库的实战背书。

缺点：与 javac 内部 API 深度耦合，JDK 每次大版本演进都要跟进适配，长期维护成本不低；规则数量多且默认组合激进，存量项目接入需要治理；文档偏薄，写自定义 BugChecker 的学习曲线陡；生态上基本只服务 Java，且对非 Bazel 构建的体验明显打折。

一句话总结：它不是又一个 linter，而是把"代码审查中反复出现的低级错误"沉淀成编译器的一部分。团队规模过了一个临界点之后，这类工具带来的收益不是线性的，而是复利式的。