Java中@NonNull方法返回null的影响及与Kotlin互操作的空安全问题

一、这类注解与返回值不一致的情况，会引发这些潜在问题： #

• 运行时空指针崩溃（NPE）：调用方如果信任@NonNull注解，直接用返回值调用方法或访问属性，会瞬间触发空指针异常。就算有人临时加了空判断，也是冗余代码，后续若有人觉得没必要删掉判断，崩溃会再次出现。要是这个方法被多模块调用，崩溃还会扩散到其他模块，排查难度陡增。
• 注解彻底失去公信力：团队成员看到这种注解和实际行为不符的情况后，再看到@NonNull就会打问号——要么每次调用都重复做无意义的空判断（浪费性能和代码量），要么干脆也不遵守注解规范，最终导致整个项目的空安全约定彻底失效。
• 调试与排查成本飙升：像你遇到的数月后才发现问题的场景，此时调用该方法的代码已经扩散到多处，且返回null的分支大概率是边缘场景（比如异常分支、特定参数触发），测试阶段没覆盖到，上线后才暴露，定位根源要花费大量时间。

二、对Kotlin互操作的空安全性影响： #

绝对会破坏Kotlin的空安全机制。

Kotlin对Java代码的空判断完全依赖注解：标记@NonNull的Java方法，在Kotlin里会被当作非空类型处理，编译器不会强制要求做空判断。一旦方法实际返回null，Kotlin代码里直接使用该值就会触发NPE——这完全绕过了Kotlin原本的编译期空安全检查，相当于把Java的空问题直接带进了Kotlin代码链路中。

更隐蔽的是，这个null值还会在Kotlin调用链里传递，比如传给非空参数，崩溃可能出现在完全不相关的位置，排查时很难联想到是Java方法的注解写错了。

补充：为什么编译器没阻止？ #

Java里的@NonNull（比如Android常用的androidx.annotation.NonNull）默认只是编译期警告，并非强制错误。只有当项目开启了严格的空检查配置（比如Android Studio的Enforce nullable/non-nullable annotations选项），编译器才会强制拦截返回null的代码。很多项目默认没开这个严格模式，就会出现注解与实际行为不符的情况。

内容的提问来源于stack exchange，提问作者Marsroverr