空指针崩溃是设计契约断裂的信号，需通过Objects.requireNonNull()前置校验、Optional规范返回、@NonNull注解静态检查、Result封装远程调用及明确null语义来系统性防护。
空指针引发的模块崩溃，根本不是“偶尔出错”，而是设计契约断裂的信号。真正能防住崩溃的，不是加一堆 if (obj != null)，而是让 null 在进入业务逻辑前就被拦截、被显式表达、被统一约束。
Objects.requireNonNull() 必须用在方法入口和构造器
这是最轻量、最明确的防御动作。它不隐藏问题，而是把失败点提前到调用方——而不是等 user.getName().length() 深层报错时才暴露。
- 只在校验不可为 null 的入参、依赖、配置项时使用，例如：
Objects.requireNonNull(repo, "repo must not be null") - 不要在循环体、高频 getter 或链式中间节点里滥用，那会掩盖真实语义
- 消息字符串必须具体，不能写
"param is null"，而要写"userService must not be null"，方便快速定位模块依赖
Optional 只能用于返回值，严禁当字段或参数
Optional 的唯一合法位置是方法签名的返回类型。把它塞进 DTO 字段、Service 方法参数、或者 JSON 序列化字段，等于把语义污染扩散到整个调用链。
- DAO 层查不到数据，应返回
Optional<user></user>，而不是User或null - 调用方必须用
.orElseThrow()或.map(...).orElse(null)显式处理分支，禁止直接调用.get() - 如果接口需要传递“可选参数”，用重载方法或 Builder 模式，别把
Optional<string></string>当参数传进来
@NonNull 注解 + IDE 静态检查才是第一道防线
靠人眼盯 == null 检查永远漏，靠运行时报错太晚。把约束写进代码里，让 IDE 在你敲下 user.getAddress().getCity() 时就标红警告。
- 用
@NonNull标记参数、字段、返回值（推荐 JetBrains 或 Checker Framework 版本，兼容性好） - IntelliJ 中开启
Settings → Editor → Inspections → Constant conditions & exceptions，自动识别未处理的 null 流 - Lombok 的
@RequiredArgsConstructor会自动为@NonNull字段生成requireNonNull校验，但注意：它不校验 setter 参数，需额外加注解
远程调用/外部输入必须封装 Result，禁止单值返回 null
模块崩溃常始于一次 HTTP 调用返回 null，接着下游无脑链式调用。这不是编码问题，是接口契约缺失。
- 所有对外服务客户端（Feign、RestTemplate 封装类）返回类型统一为
Result<user></user>，其中data字段永不为 null，查不到时data是默认空对象或 Optional.empty() - JSON 反序列化一律用
@JsonInclude(JsonInclude.Include.NON_NULL)控制输出，但接收端必须用@NotNull或Objects.requireNonNull校验关键字段 - 配置项读取（如
System.getProperty("timeout")）必须兜底：Integer.parseInt(Objects.toString(System.getProperty("timeout"), "3000"))
最易被忽略的点是：null 不是一种状态，而是一组混杂语义的占位符——“没查到”“没传”“初始化失败”“故意留空”。不区分它们，就永远在补洞。防护的本质，是把每种 null 背后的业务意图，用类型、注解、封装结构明确定义出来。
