Go中不能直接用nil作空对象，因nil非值而是未初始化占位符，无法调用方法或实现接口；空对象模式应提供默认行为而非仅防panic，需实现相同接口且无状态、不扩展方法。
Go 里为什么不能直接用 nil 当“空对象”
因为 Go 的 nil 不是值，而是未初始化的零值占位符；它不能调用方法，也不能参与接口实现——一旦你写了 if obj == nil 再调方法，就掉进防御式编程陷阱了。
空对象模式的核心不是“避免 panic”，而是让“无意义的行为”变成“有意义的默认行为”。比如日志器为空时该静默，通知器为空时该跳过，而不是每处都加 if logger != nil。
常见错误现象：panic: runtime error: invalid memory address or nil pointer dereference，表面是解引用 nil，深层原因是把控制逻辑（有没有）和业务逻辑（做什么）混在了一起。
定义空对象：必须实现同一接口，且方法体为空或返回零值
空对象不是新类型，而是对已有接口的“哑实现”。关键在于：它和真实对象共用同一个接口，调用方完全无感。
立即学习“go语言免费学习笔记（深入）”；
示例场景：一个支付回调处理器需要通知下游系统，但测试环境不发通知。
type Notifier interface {
Send(message string) error
}
type NullNotifier struct{}
func (n NullNotifier) Send(message string) error {
return nil // 或 log.Printf("[null] dropped: %s", message)
}
使用时直接注入：svc := NewService(NullNotifier{})，后续所有 notifier.Send(...) 都安全执行，无需检查。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 别给空对象加字段——它不该持有状态
- 别让它实现额外方法——只实现接口声明的部分
- 如果接口返回非 error 类型（如
int），空对象应返回合理零值（0），而非0, false这类双返回值来模拟“不存在”
什么时候不该用 Null Object
不是所有 nil 都适合被“消解”。空对象只适用于语义上“可选但行为明确”的依赖，比如日志、监控、通知、缓存客户端。
以下情况绕不开显式判断，强行套空对象反而模糊意图：
- 业务实体本身可能是空的（如
user := db.FindUser(id)返回nil），此时nil是有效业务信号，代表“查无此人”，不该用NullUser{}掩盖 - 函数返回指针且需区分“未设置”和“设为空字符串”等语义时，
*string的nil本身就是契约的一部分 - 性能敏感路径（如高频循环内），空对象的接口动态分发比直接判
nil多一次间接跳转，虽微小但可测
测试中如何自然引入 Null Object
单元测试里最常需要空对象——比如测试 HTTP handler 时不希望真发邮件。这时别在测试文件里重复写一遍 NullNotifier，而是在包内提供导出的实例。
推荐做法：
var (
NullNotifier = NullNotifier{}
NullLogger = NullLogger{}
)
这样测试代码干净：svc := NewService(NullNotifier)，而不是 svc := NewService(testing.NullNotifier{}) 或更糟的 svc := NewService(struct{...}{})。
容易踩的坑：
- 忘记导出变量名（首字母小写），导致测试无法访问
- 把
NullNotifier{}写成指针&NullNotifier{}，造成接口实现不一致（值接收者 vs 指针接收者） - 在多个包里各自定义同名空类型，破坏接口一致性
真正难的不是写一个空结构体，而是判断某个依赖在当前上下文里，“不存在”是否等价于“什么也不做”。这个边界划错，空对象就会从简化工具变成隐藏 bug 的温床。
