空对象模式是为避免nil panic而让接口调用安全返回零值的兜底机制，需完整实现接口、无副作用、类型严格匹配，并通过DI容器规范注册而非条件判断。
Go 里依赖注入失败时，nil 值直接 panic 是最常见的崩溃原因
空对象模式不是为了“假装有依赖”，而是让系统在依赖缺失时仍能跑通基础流程，避免 nil pointer dereference。关键不是构造一个“假实现”，而是让接口调用不爆炸——哪怕返回默认值、静默丢弃、或走降级逻辑。
用空对象替代 nil 接口值，必须确保类型完全匹配
Go 的接口是隐式实现，空对象必须满足目标接口所有方法签名，且不能漏掉任何返回值。常见错误是只实现部分方法，或返回值数量/类型对不上，导致编译失败或运行时 panic。
实操建议：
- 用 IDE 或
go vet检查是否完整实现了接口（尤其注意多返回值，比如func() (int, error)忘写error就会报错） - 空对象的每个方法体优先用
return直接返回零值，不要加日志或副作用——那是调试阶段的事，上线后要干净 - 如果原接口方法带指针接收者，空对象也得用指针实例赋值，否则类型不匹配：
var obj *EmptyLogger而不是var obj EmptyLogger
Provide 函数里别硬写 if-else 判 nil，改用注册空对象作为 fallback
很多人在 DI 容器（如 Wire、fx）的 Provide 函数里写 if dep == nil { return new(EmptyService) }，这看似安全，实则破坏了依赖图的可预测性：一旦上游注入逻辑变更，这个判断就容易失效或被绕过。
立即学习“go语言免费学习笔记（深入）”；
更稳的做法是把空对象当成一种合法实现，和真实实现并列注册，并靠依赖顺序或标签控制优先级：
- Wire 中用
wire.Value显式提供空对象实例，放在真实 provider 之后，利用 Wire 的“最后注册胜出”规则 - fx 中用
fx.Provide(newEmptyRepo)并配合fx.Replace或模块分组，避免条件逻辑混入 DI 配置 - 空对象的构造函数应无副作用、不依赖其他服务、不读配置——它必须是“最轻量的兜底”
空对象不是日志开关，别在里面埋 log.Printf 或指标上报
开发时加日志方便排查，但上线后这些输出会污染日志、拖慢性能，还可能掩盖真正的问题——比如你看到空对象被调用了 1000 次，却没意识到这是依赖根本没注入成功。
实操建议：
- 空对象的方法体保持绝对安静，连
fmt.Print都不该有 - 真要观测是否退到了空对象？用独立的 health check 接口或 metrics counter，由外部统一采集，而不是塞进空对象内部
- 测试时可用临时包装器（比如
CountingEmptyLogger）统计调用次数，但生产代码里必须删掉
最常被忽略的一点：空对象一旦启用，它就接管了整个调用链。如果下游服务基于它的返回值做决策（比如根据 user.ID 是否为 0 判断登录态），那这个“安全退回”反而成了隐藏 bug 的温床——得确认业务逻辑真的能容忍零值语义。
