NullAway：把空指针检查塞进每次编译的 Java 注解工具
一种帮助消除 Java 代码中的 NullPointerExceptions (NPE) 的工具，并且构建时间开销较低。
秒懂
- 它是什么？
- NullAway 是 Uber 开源的基于注解的空指针检查工具，以 Error Prone 插件形式运行，号称编译开销通常低于 10%。它适合愿意为代码加 @Nullable 注解、且能接受 Error Prone 的团队。
- 适合谁用？
- NullAway 适合已经在用 Error Prone、且愿意在代码中标注 @Nullable 的 Java 团队，尤其是那些被 NPE 困扰但不想引入 Kotlin 或完整类型检查器的项目。不适合不愿意承担注解负担、或者代码中大量使用未标注的第三方库的项目，因为 NullAway 要求显式标注可空性，否则会误报或漏报。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 Java（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决什么问题，谁该用它
NullAway 的目标很具体：在 Java 代码中消灭 NullPointerException。它不像静态分析工具那样事后扫描，而是作为 Error Prone 的一个插件，在每次编译时运行。你需要在代码里给可能为 null 的字段、方法参数和返回值加上 @Nullable 注解，然后 NullAway 会做一系列基于类型的局部检查，确保任何被解引用的指针不可能是 null。这个思路和 Kotlin、Swift 的类型系统类似，也跟 Checker Framework 和 Eradicate 这些 Java 检查器有重叠。它面向的是那些不想迁移语言、但又受够 NPE 的 Java 团队。根据 README 的说法，NullAway 的编译开销通常低于 10%，所以它可以跑在每一次构建上，而不是像某些工具那样只在 CI 里跑。
实际机制：注解驱动的局部检查
NullAway 不是全局数据流分析，它做的是类型层面的局部检查。你给代码加上 @Nullable 注解后，NullAway 会追踪每个表达式的可空性状态。比如一个方法返回 @Nullable 值，那么调用方直接解引用这个返回值就会报错。它不试图证明所有可能的 NPE，而是抓住生产环境中观察到的大部分情况。README 明确说它“不防止所有可能的 NPE”，但换来的是合理的注解负担。这种取舍很实际：它牺牲了完备性，换来了速度和易用性。它要求配置 AnnotatedPackages 或 OnlyNullMarked 二选一，目的是区分已标注和未标注的代码，这决定了检查的边界。
安装与配置：Gradle 下的真实步骤
安装 NullAway 需要 JDK 17 以上和 Error Prone 2.36.0 以上。以 Gradle 为例，在 build.gradle 里加插件 net.ltgt.errorprone，然后在 dependencies 里加 errorprone "com.uber.nullaway:nullaway:<版本>"，同时加一个注解库，README 推荐 JSpecify 1.0.0，但也支持 AndroidX 或 JetBrains 的 @Nullable。还要加 errorprone "com.google.errorprone:error_prone_core:<版本>"。最后在 tasks.withType(JavaCompile) 里配置：check("NullAway", CheckSeverity.ERROR) 把问题设为错误级别，默认是警告；option("NullAway:AnnotatedPackages", "com.uber") 指定检查哪个包。这里有个关键点：NullAway 要求必须配置 AnnotatedPackages 或 OnlyNullMarked 之一，否则不运行。如果你不想跑其他 Error Prone 检查，可以用 options.errorprone.disableAllChecks。
Android 与生成代码的坑
Android 项目要注意：Gradle Error Prone 插件 3.0.0 以后不再支持 Android，所以要么用 2.x 版本，要么参考 sample-app 里的 build.gradle 做额外配置。另外，Dagger 和 AutoValue 这类注解处理器会生成代码，这些代码如果在同一个包下，NullAway 报错会阻塞构建。README 给出的方案是用 Error Prone 的 -XepExcludedPaths 选项把生成代码目录排除掉。还有个历史坑：Dagger 2.12 之前的版本和 NullAway 有不良交互，README 明确建议更新到 2.12。这些细节说明 NullAway 不是开箱即用的，它和构建链的耦合比想象中深。
JSpecify 模式与 Guava 的关联
README 提到 JSpecify 模式，并建议用最新 JDK 构建。JSpecify 是 Java 官方的可空性注解标准，NullAway 从 0.14.0 开始支持它。文档里还专门提到 Guava 33.4.1 版本，这可能是因为 Guava 开始使用 JSpecify 注解，导致 NullAway 需要处理这些注解。这个细节表明，NullAway 的检查范围受依赖库的标注情况影响。如果第三方库没有标注，NullAway 会假设它们不可空，这可能产生误报。所以采用 NullAway 时，你需要评估自己的依赖生态。
与 Checker Framework 的路线差异
NullAway 的替代品是 Checker Framework 和 Eradicate。Checker Framework 是更全面的类型检查框架，它支持多种检查器，包括可空性检查，但它的编译开销和配置复杂度都更高。Eradicate 是 Facebook Infer 里的一个检查器，它做的是 interprocedural 分析，能跨方法追踪，但需要运行整个分析流程。NullAway 选择了另一条路：它只做局部检查，依赖注解，把开销控制在 10% 以内。这意味着它无法发现跨方法的空指针问题，但换来了可以每次编译都跑。如果你的项目需要深度分析，Checker Framework 可能更合适；如果你要的是低开销的日常检查，NullAway 更实际。
维护成本与许可证
NullAway 采用 MIT 许可证，这对商业项目友好，没有 copyleft 限制。维护成本方面，它依赖 Error Prone 的版本，Error Prone 更新时你可能需要跟着升级。README 建议处理所有 Error Prone 报告的问题，尤其是错误级别，这意味着引入 NullAway 后，你需要清理现有的潜在空指针问题，这可能是初始成本。另外，配置项 AnnotatedPackages 或 OnlyNullMarked 需要你理解代码结构，否则容易配置错。长期来看，NullAway 的版本更新频率不算低，但作为编译插件，升级通常只是改个版本号。
编辑结论
NullAway 适合已经在用 Error Prone、且愿意在代码中标注 @Nullable 的 Java 团队，尤其是那些被 NPE 困扰但不想引入 Kotlin 或完整类型检查器的项目。不适合不愿意承担注解负担、或者代码中大量使用未标注的第三方库的项目，因为 NullAway 要求显式标注可空性，否则会误报或漏报。采用前先确认你的构建环境满足 JDK 17 和 Error Prone 2.36.0 的要求，并检查生成代码（如 Dagger、AutoValue）是否会被 NullAway 误报，必要时用 excludedPaths 排除。还要决定使用 AnnotatedPackages 还是 OnlyNullMarked 模式，这直接影响检查范围。如果你能接受这些约束，NullAway 是一个把空指针检查前置到编译期的实用选择。
社区笔记