空对象模式是用有行为、有语义的默认对象替代null，解决调用方需安全调用方法的设计问题；适用于“空”为有意义业务状态的场景，如未登录用户、无优惠券、日志未启用等，而非错误情形。
空对象模式不是用来“消灭 null”，而是把“null 该干的事”变成一个有行为、有语义的对象。它解决的不是语法问题，而是设计问题——当某个对象可能不存在，但调用方又必须能安全调用其方法时，用一个默认行为明确的空对象来承接，就能自然绕过层层 if (obj != null)。
什么时候该用空对象，而不是 Optional 或判空？
关键看“空”是否代表一种有意义的业务状态：
- 用户未登录 → 返回 NullUser，
getName()返回“游客”，getRole()返回“GUEST”，placeOrder()静默失败或跳转登录页；这不是异常，是常态 - 订单无优惠券 → 返回 NullCoupon，
getDiscount()返回 0.0，getDescription()返回“暂无可用优惠”；调用方直接累加，无需分支 - 日志模块未启用 → 返回 NullLogger，所有
info()、error()方法为空实现；上层完全不感知开关逻辑
如果“空”意味着错误（比如数据库连接丢失、配置项强制必填却缺失），那就该抛异常或用 Optional 显式暴露不确定性，而不是掩盖。
怎么写出真正好用的空对象？
空对象不是“随便返回个默认值”，它得让调用方感觉不到差异：
- 接口一致：和真实对象实现完全相同的接口，连返回类型、参数顺序、异常声明都不能变
- 行为合理：返回值要符合上下文语义——集合类返回空列表（不是 null），数值类返回 0 或 1（非负场景下），字符串类返回 "" 或 "N/A"，布尔类返回 false（除非“默认开启”是业务约定）
- 无副作用：不能修改状态、不发请求、不打日志、不触发回调；它的存在只为“让链式调用不断掉”
-
可识别可调试：重写
toString()，比如"NullUser{id: -1, name: '匿名'}"；必要时加isNull()方法，方便排查
工厂 + 接口 + 空对象，三件套落地最稳
避免在业务代码里 new NullXXX，统一交给工厂管理：
- 定义抽象接口
UserService，含findUserById(Long) - 真实实现
DbUserService，查不到就委托给NullUserService.getInstance() - 空实现
NullUserService是单例，所有方法返回安全默认值 - 客户端只依赖
UserService，写service.findUserById(123).getName().toUpperCase()就行，完全不用 try/catch 或判空
这种结构天然支持策略切换——灰度期间，工厂可按规则返回 Real 或 Null 实现，业务线无感。
注意边界：别让空对象变成“黑洞”
空对象模式不是银弹，滥用反而掩盖问题：
- 数据库主键查询返回 NullUser？可以，这是常见缺省
- 用户提交表单后，
user.getAddress().getCity()返回 "未知城市" 却继续下单？危险——这已脱离“空”的语义，属于数据缺失风险，应拦截或提示 - 空对象内部偷偷记录埋点或上报监控？违背“无副作用”原则，会干扰可观测性
核心判断标准：调用空对象的方法后，业务流程是否仍能给出**可预期、可解释、可审计**的结果。如果不是，那就不是该用空对象的地方。
