空对象模式是用可交互对象替代null，适用于有明确行为契约的接口/抽象类场景，如nulldeliverypolicy；不适用于简单字段或语义模糊的null，需避免泛滥且确保行为可预期、易识别、无副作用。

空对象模式不是为了“消灭 null”，而是用一个真正可交互的对象替代 null，让调用方无需关心“有没有”，只管“怎么用”。它真正起效的地方，是当多个业务分支反复出现 if (obj != null) { ... } 或 Optional.ofNullable(...).map(...) 时——这时引入空对象，代码会立刻变干净。

什么时候该用空对象，而不是 Optional 或判空？

空对象适合有明确行为契约的接口或抽象类场景。比如订单服务中有个 DeliveryPolicy 接口，不同地区实现不同配送规则；但某些新上线城市还没配置策略，此时返回 null 会让所有调用方加判空，而返回一个 NullDeliveryPolicy（默认不加急、不补贴、不校验库存），就能让主流程完全无感。

• ✅ 适用：接口/抽象类已存在，且“无行为”本身有明确语义（如“不执行”“跳过”“返回空集合”）
• ❌ 不适用：简单字段（如 String name）、DTO 中的原始类型包装类、或“空”含义模糊（比如用户对象为 null，是未登录？还是查无此人？语义不统一）
• ⚠️ 注意：不要为每个可能为 null 的变量都建一个空对象——那会泛滥。优先覆盖高频、跨多处使用的协作角色

如何设计一个真正好用的空对象？

关键不是“让它不报错”，而是“让它行为可预期、易识别、难误用”。一个合格的空对象应满足：

• 实现同一接口，且方法全部非空返回：避免在空对象里又抛 NPE 或返回 null，例如 getItems() 返回 Collections.emptyList()，而非 null
• 显式命名，拒绝隐晦：用 NullPaymentGateway，别叫 DefaultPaymentGateway——后者容易让人误以为是真实默认实现
• 重写 toString() 和 isPresent()（如有）等辅助方法：便于日志排查和调试，例如返回 "NullPaymentGateway[disabled-by-config]"
• 禁止在空对象里做副作用操作：比如发消息、改状态、打日志（除非明确用于追踪空路径）

与 Spring、Lombok 等框架协同的实用技巧

在真实项目中，空对象常配合依赖注入使用：

• Spring 中可用 @Primary + 条件化 Bean（@ConditionalOnMissingBean）自动兜底：当业务未注册具体策略 Bean 时，自动装配空对象实例
• Lombok 的 @UtilityClass 可封装空对象的静态获取入口，如 NullDeliveryPolicy.instance()，比每次 new 更清晰
• 若已有大量判空逻辑，可先提取共用方法（如 safeGetPolicy(user)），内部统一返回空对象——逐步迁移，不强求一步重构

一个微小但关键的提醒

空对象不是银弹。它解决的是“调用链上重复防御性检查”的问题，不是“数据缺失”的问题。如果某处频繁拿到 null，更该问的是：为什么这个对象本该存在却没构造出来？是上游漏了初始化？配置没加载？还是领域模型本身没表达清楚“可选性”？ 空对象只是优雅地掩盖症状，真正的根因仍需追溯。