NATS最轻量适合内部微服务通信，kafka+ sarama支持持久化与多分区；channel仅限单进程goroutine通信，跨服务无效；NATS需显式Subscribe且主题名严格匹配；Kafka消费需谨慎选择OffsetNewest/OffsetOldest并手动提交offset。
用 nats.go 实现事件订阅最轻量、启动最快，适合内部微服务通信；若需持久化、重试、多分区消费，则必须换 Kafka + sarama。
为什么不能直接用 channel 做跨服务订阅
本地内存级 chan 看似简单，但微服务是独立进程——user-service 和 email-service 不在同一个地址空间，发到 chan 的消息另一方根本收不到。硬用会卡死或 panic，常见错误是：fatal Error: all goroutines are asleep - deadlock!。
- channel 只适用于单进程内 goroutine 通信，不是消息中间件替代品
- 没有持久化：服务重启后未消费事件全丢
- 无广播能力：一个事件无法同时通知多个服务（如 email + sms + audit）
- 无确认机制：消费者处理失败，没人知道该重发
nats.Connect() 后必须显式调用 Subscribe() 才能收事件
NATS 默认不自动监听任何主题，连接成功只是“通了网”，不等于“开了收音机”。漏掉这步会导致服务静默运行、日志无报错、但永远收不到 "user.created" 这类事件。
nc, err := nats.Connect(nats.DefaultURL) if err != nil { log.Fatal(err) } // ✅ 必须手动订阅 nc.Subscribe("user.created", func(msg *nats.Msg) { var event UserCreatedEvent if err := json.Unmarshal(msg.Data, &event); err != nil { log.Printf("parse fail: %v", err) return } sendWelcomeEmail(event.Email) }) // ❌ 没有这一行，代码跑得再快也收不到消息- 主题名（subject）要和发布方完全一致，大小写敏感，不支持通配符模糊匹配（除非用
SubscribeSync配合 wildcard） - 回调函数里别直接做耗时操作（如发邮件），建议起 goroutine 或投递到 worker pool，避免阻塞 NATS 内部 reader
- 如果需要确保至少一次投递，要用
QueueSubscribe+ 消费组，否则默认是广播模式，每个订阅者都收到一份
用 sarama 订阅 Kafka 时，OffsetNewest 和 OffsetOldest 切换影响极大
新消费者第一次连 Kafka，默认从最新 offset 开始读（OffsetNewest），意味着它会跳过所有历史事件。上线灰度时经常发现“老用户没收到欢迎邮件”，就是因为这个配置没改。
立即学习“go语言免费学习笔记（深入）”；
-
OffsetNewest：只收启动后的新事件，适合测试环境或事件幂等性极强的场景 -
OffsetOldest：从最早一条开始读，上线初期用于补数据，但要注意重复消费风险 - 生产环境推荐用
OffsetNewest+ 外部存储记录已处理的order_id，靠业务层去重 - 别依赖 consumer group 自动 commit offset ——
sarama默认关闭 auto-commit，必须手动调用MarkOffset，否则重启就重放
真正难的不是写几行 Subscribe，而是决定事件边界：一个“订单创建”事件，该不该包含用户手机号？库存扣减要不要等它？这些业务语义一旦定错，后面加字段、改格式、做兼容，比换中间件还疼。