go中空对象必须显式定义为具体类型，因其无null语法糖和继承机制，需用零值安全、可共享的导出struct实现接口，且所有方法无副作用。
空对象模式在 Go 里不是靠继承或接口多态“强制实现”的，而是靠返回一个实现了接口但所有方法都无副作用的结构体实例——它有效消除了大量 if obj != nil 检查，但 Go 的简洁性也意味着你得亲手控制它的边界。
为什么 Go 中的空对象必须显式定义为具体类型
Go 没有 null 对象的语法糖（比如 Java 的 NullUser 类），也没有可继承的基类。空对象必须是一个真实存在的、实现了目标接口的 struct，且所有方法逻辑为空或返回零值。
- 不能用
nil指针代替：调用nil接口变量的方法会 panic（除非方法明确允许 nil receiver） - 空对象类型应导出（首字母大写），否则无法被其他包使用
- 推荐把空对象命名为
EmptyXXX或NilXXX，例如EmptyLogger、NilHandler
如何安全地构造空对象并避免内存/语义陷阱
空对象应是零值安全的、可共享的、不可变的。最稳妥的方式是定义一个包级变量，复用同一实例，而不是每次 new(EmptyService)。
- 用
var EmptyService Service = emptyService{}声明全局单例，避免重复分配 - receiver 必须用指针还是值？取决于接口方法签名：如果接口方法接收者是
*emptyService，那你的空对象变量也必须是指针类型；多数情况下用值类型 receiver 更轻量且线程安全 - 不要在空对象方法里偷偷修改状态（如计数器、日志写入），否则就违背了“空”的语义
空对象与 error 返回的取舍场景
不是所有“不存在”都适合用空对象。当缺失资源本身代表异常流程（如数据库查不到用户应触发告警或重试），返回 nil, ErrNotFound 更合适；只有当“不存在”是合法且高频的业务常态（如配置项未设置、可选回调未注册），空对象才真正降低认知负担。
立即学习“go语言免费学习笔记（深入）”；
- 典型适用：日志器
Logger接口、事件总线EventEmitter、策略接口RateLimiter - 典型不适用：
UserService.GetUser(id)—— 用户不存在通常需上层决策，不是静默忽略 - 可组合：空对象内部仍可返回 error（如
EmptyDB.Query() error { return sql.ErrNoRows }），但调用方无需判空，只需处理 error
最容易被忽略的是空对象的测试覆盖——它不报错，也不做任何事，但一旦漏掉某个接口方法的空实现，编译就过不去；而更隐蔽的问题是：有人给空对象加了日志或埋点，让它悄悄“变重”，结果线上流量全打到空分支却毫无感知。
