使用@Nonnull注解后，是否仍需处理方法参数的null值？

这本质是在注解的编译期提示价值和运行时防御性编程之间做权衡，没有绝对的对错，得看代码场景和团队规范：

反方观点：依赖注解，保持代码简洁 #

用@Nonnull标记参数的核心优势是代码更清爽，尤其是当方法有多个非空参数时，不需要写一堆重复的null检查代码，可读性反而更高。

示例代码：

private void foo(@Nonnull Object o) {
    /* 业务逻辑 */
}

对比手动检查的版本，少了冗余的判断逻辑，更聚焦业务本身：

public void foo(Object o) throws NullPointerException {
    if (o == null) {
        throw new NullPointerException("Given Object must have a value!");
    }
    /* 业务逻辑 */
}

这种做法适合内部私有方法或者团队严格遵守注解规范、配合静态检查工具的场景——静态检查会在编译期就提示开发者不要传null，从源头避免问题。

正方观点：手动检查，避免注解被忽略 #

@Nonnull本质是编译期注解，它本身不会在运行时做任何校验。如果后续开发者没注意到注解（比如用了不识别该注解的IDE，或者根本没看方法注释），直接传了null，就会在业务逻辑里触发未捕获的NullPointerException，排查起来反而麻烦。

这种做法更适合对外暴露的公共API，因为你无法控制调用方的开发环境和规范，手动加null检查相当于给方法加了一层运行时的“安全网”，能提前抛出明确的异常信息，方便调用方定位问题。

折中方案 #

如果想兼顾简洁性和安全性，可以：

• 私有方法：只用@Nonnull标记，配合团队静态检查规范
• 公共方法：@Nonnull标记 + 简洁的null检查（比如用Objects.requireNonNull()替代手动if判断），代码不会太冗余：

  public void foo(@Nonnull Object o) {
      Objects.requireNonNull(o, "Given Object must have a value!");
      /* 业务逻辑 */
  }
  

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