应主动用Objects.requireNonNull()校验入口参数，用Optional显式表达可能为空的返回值，配合@Nullable/@NonNull注解和IDE静态检查，辅以StringUtils.isBlank()等工具方法处理字符串集合判空，并通过单元测试覆盖“半空”边界场景。
用 Objects.requireNonNull() 主动拦截 null
空指针异常（NullPointerException）多数发生在方法内部对参数或字段未校验就直接调用方法或访问属性。与其等运行时崩溃，不如在入口处明确拒绝 null。Java 7 引入的 Objects.requireNonNull() 是最轻量、语义最清晰的防御手段。
- 它会在传入
null时立即抛出带消息的NullPointerException，堆栈指向调用点而非深层访问点，排查更快 - 适合校验方法参数、构造函数入参、不可变字段初始化——例如：
public UserService(UserRepository repo) { this.repo = Objects.requireNonNull(repo, "repo must not be null"); } - 避免滥用：不要在循环体内或高频路径上反复调用；也不该用来替代业务逻辑中的合法
null场景（如可选查询结果）
用 Optional 显式表达“可能为空”的契约
当一个值天然可能不存在（比如数据库查询未命中、配置项未设置），用 null 表示会把“空”的语义隐含在调用方，极易漏判。改用 Optional 能强制调用方处理两种分支。
- 返回值用
Optional：DAO 方法返回Optional而非User，调用方必须显式调用.isPresent()、.orElse()或.ifPresent() - 禁止将
Optional用作字段或方法参数
——它不是容器类，设计初衷仅用于返回值
- 警惕
Optional.get()：它不加判断直接取值，和直接解引用null风险等同；应优先用.orElse(null)或.orElseThrow()
用 IDE 和注解提前暴露潜在空值
静态检查比运行时异常更早发现问题。IntelliJ 和 Eclipse 都支持基于注解推断空值流，配合编译期检查能拦截大量隐患。
- 在参数、字段、返回值上添加
@Nullable（JetBrains）或@NonNull（AndroidX / Checker Framework），IDE 会在不安全解引用时报黄线甚至错误 - Maven/Gradle 中启用
-Xlint:unchecked和-Xlint:cast等基础检查；更进一步可集成error-prone或NullAway做编译期空值分析 - 注意：注解本身不改变运行行为，但若搭配 Lombok 的
@RequiredArgsConstructor(onConstructor_ = {@NonNull})，可自动生成非空校验代码
字符串和集合的空值惯用写法
字符串判空、集合判空是高频操作，手写 str != null && !str.isEmpty() 容易遗漏或顺序写反，且无法复用。标准库和常用工具类已提供可靠方案。
- 字符串：优先用
StringUtils.isBlank(str)（Apache Commons）或String.valueOf(obj).trim().isEmpty()（避免 NPE），禁用str.isEmpty()前不判null - 集合：用
CollectionUtils.isEmpty(list)或 Java 8+ 的list == null || list.isEmpty()；避免list.size() == 0——它在null时直接炸 - 数组：用
ArrayUtils.isEmpty(arr)；原始类型数组（如int[]）更要小心，arr.length对null同样抛 NPE
null，而是被多层封装后悄然透出的“半空”状态——比如 Optional.empty() 被误转成 null 返回，或 JSON 反序列化时字段缺失却未设默认值。这类问题不会被静态检查捕获，得靠单元测试覆盖边界输入，以及日志中记录关键对象的非空断言。
