本文讲解如何通过合理使用 @NotNull 注解、重写安全的 getter 方法及构造时校验，向 IntelliJ 和团队开发者清晰传达子类中继承字段的实际非空性，避免误报警告且不牺牲运行时安全性。

本文讲解如何通过合理使用 `@notnull` 注解、重写安全的 getter 方法及构造时校验，向 intellij 和团队开发者清晰传达子类中继承字段的实际非空性，避免误报警告且不牺牲运行时安全性。

在 IntelliJ 中，当你继承一个声明为 @Nullable 的 final 字段（如 propertyA），即使子类构造器强制传入非空值，IDE 仍会基于父类声明发出“可能为 null”的警告——因为类型系统只认声明，不推断子类约束。直接使用 assert propertyA != null 并不可取：它仅在启用断言时生效（生产环境默认关闭），无法被静态分析工具识别，也不能向协作者传达明确契约。

✅ 推荐做法是组合使用三重保障：

1. 子类中提供带 @NotNull 的重写 getter（最轻量、最直观）

   class A {
       @Nullable
       final String propertyA;
   
       public A(@Nullable String propertyA) {
           this.propertyA = propertyA;
       }
   
       // 父类默认 getter（可选）
       @Nullable
       public String getPropertyA() {
           return propertyA;
       }
   }
   
   class B extends A {
       public B(@NotNull String propertyA) {
           super(propertyA);
           // 运行时强制校验，防御性编程
           if (propertyA == null) {
               throw new IllegalArgumentException("propertyA must not be null");
           }
       }
   
       // 关键：重写 getter 并标注 @NotNull
       @Override
       @NotNull
       public String getPropertyA() {
           return propertyA; // 此处 IDE 不再警告
       }
   
       public void doSomething() {
           // ✅ 安全调用，无警告，语义清晰
           System.out.println(getPropertyA().length());
       }
   }

2. 构造器内显式校验（必须！）
   @NotNull 仅是编译期提示，不能替代运行时检查。务必在 B 的构造器中验证参数非空，否则 null 仍可能绕过注解进入对象状态。

3. 避免直接访问字段，统一走 getter
   即使字段是 final，也应通过 getPropertyA() 调用。这既利用了注解的语义传递，又保持了封装性——未来若需添加逻辑（如懒初始化），无需修改调用方。

⚠️ 注意事项：

• 不要依赖 assert 消除警告：它不参与编译期检查，也不被其他工具（如 SpotBugs、ErrorProne）识别；
• 避免在字段上重复加 @NotNull（如 @NotNull final String propertyA）：这与父类声明冲突，且违反 Liskov 替换原则；
• 若项目使用 JetBrains Annotations，请确保已引入 org.jetbrains:annotations 依赖，并在 IntelliJ 中启用「Enable annotation-based nullability inspection」（Settings → Editor → Inspections → Java → Nullability issues）。

总结：用重写 @NotNull getter + 构造器校验 + 封装访问，才是兼顾 IDE 友好性、代码可读性与运行时健壮性的标准实践。