纯内存observer不适合跨服务通知，因其依赖进程内sync.map或切片，多实例部署时观察者列表无法共享，导致事件仅本机可达、其他服务失联，本质是“断连”而非解耦。
为什么纯内存 Observer 不适合跨服务通知
因为 Go 的 sync.Map 或切片维护的观察者列表只在当前进程有效，一旦服务拆分成多个实例（比如用户服务、订单服务、风控服务各跑一个 Pod），内存里的 observers 就完全失联了。你调用 Publish()，只有本机 goroutine 能收到，其他服务一无所知——这不是“解耦”，是“断连”。
- 常见错误现象：
本地测试全通，上线后一半事件没人处理 - 根本原因：把进程内通信模型（Observer）直接套用到分布式场景
- 正确思路：Observer 留给模块内轻量交互；跨服务必须走消息队列，比如 Kafka、NATS 或 RabbitMQ
- 性能影响：消息队列引入网络 IO 和序列化开销，但换来的是可靠性、重试、广播、回溯能力——这些是内存 Observer 根本不提供的
如何让 Publisher 无感切换本地 vs 远程事件分发
关键不是写两套代码，而是抽象出统一的 EventPublisher 接口，背后可插拔不同实现。本地用 inmem.Publisher（基于 sync.Map + chan Event），远程用 kafka.Publisher（封装 sarama.SyncProducer），上层业务代码完全不用改。
- 接口定义只需：
type EventPublisher interface { Publish(topic string, event Event) error } - 所有事件结构体必须实现
Event接口（含Topic()和Timestamp()），避免interface{}导致的运行时 panic - 不要在
Publish()里做 JSON 序列化——由具体实现决定格式（Kafka 可能用 Protobuf，本地可直传 struct 指针） - 测试时用
mock.Publisher实现空写入，避免启动真实 MQ
订阅端怎么避免重复消费和 goroutine 泄漏
本地 channel 订阅靠 close() + sync.Map 清理；而从 Kafka 订阅，Unsubscribe 这个动作本身就不成立——你退订的是消费者组位点（offset），不是内存句柄。
- 重复消费典型场景：
Consumer.Commit() 失败后 offset 未更新，重启又拉取旧消息 - 解决办法：用
auto.offset.reset=earliest配合业务幂等（如 DB 唯一索引或 Redis setnx） - goroutine 泄漏风险：Kafka consumer 启动 goroutine 拉取消息，若没调用
consumer.Close()，该 goroutine 会一直卡在ReadMessage() - 安全做法：把 consumer 生命周期绑定到
context.Context，在ctx.Done()触发Close()和资源清理
Event 结构体设计要兼顾本地效率与远程兼容性
很多人定义 type UserCreatedEvent struct { UserID int; Name string; CreatedAt time.Time }，本地用着爽，但发到 Kafka 就得手动映射字段、补 topic、加时间戳——错一处就丢事件。
立即学习“go语言免费学习笔记（深入）”；
- 推荐最小契约：
type Event interface { Topic() string; Timestamp() int64; Payload() []byte } - 所有事件类型都包装成这个接口，
Payload()返回已序列化的字节（JSON/Protobuf），Topic()返回固定字符串（如"user.created"） - 这样 Publisher 不关心结构体字段，只管发；Subscriber 收到后按
Topic()分发给对应 handler，解耦彻底 - 别用
time.Time字段直接塞进 struct——序列化时区、精度、零值表现不一致，统一用int64时间戳
