不能用channel做跨服务订阅，因为channel仅限单进程goroutine通信，user-service和payment-service是独立进程、内存不共享，发往chan的消息另一方根本无法访问，硬用会导致deadlock；且无持久化、无广播、无确认机制。
为什么不能用 channel 做跨服务订阅
因为 channel 是进程内通信机制，user-service 和 payment-service 是两个独立进程，内存不共享。往 chan 里发消息，另一方根本看不到——不是“收不到”，是压根不存在这个地址空间。硬写会直接触发 fatal error: all goroutines are asleep - deadlock!。
常见误用场景：本地测试时一切正常，一上 Kubernetes 就静默失联；或者把 chan 当成全局消息总线，结果只在单个 Pod 内流转，其他实例完全无感知。
- 没有持久化：服务重启后未消费消息全丢
- 无广播能力：一个事件无法同时通知 email、sms、audit 三个服务
- 无确认机制：消费者 panic 或超时，没人知道该重发
NATS 订阅必须显式调用 Subscribe()
nats.Connect() 只建立 TCP 连接，不代表开始收消息。就像连上 Wi-Fi 不等于打开了微信——你得手动点进某个群聊才能看到消息。
漏掉 Subscribe() 是最隐蔽的 bug：服务启动成功、日志干净、CPU 正常，但 "order.created" 事件永远不来。主题名大小写敏感，且不支持模糊匹配（"order.*" 无效，除非用 QueueSubscribe 配合通配符）。
- 主题名必须和发布方完全一致：
"user.created"≠"User.Created" - 回调函数里别做耗时操作（如发邮件），建议起
goroutine或投递到 worker pool，否则阻塞 NATS 内部 reader - 需要确保至少一次投递？用
QueueSubscribe()+ 消费组，否则默认是广播模式，每个订阅者都收到一份
Kafka offset 设置直接影响上线行为
新消费者第一次连接 Kafka，默认从 OffsetNewest 开始读——它会跳过所有历史事件。灰度上线时经常发现“老用户没收到欢迎邮件”，问题就出在这。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
OffsetNewest 适合测试环境或事件天然幂等的场景；OffsetOldest 才是上线初期补数据的正确选择，尤其涉及用户生命周期类事件（注册、升级、注销）。
- 用
sarama时，config.Consumer.Offsets.Initial必须显式设为sarama.OffsetOldest或sarama.OffsetNewest - 手动提交 offset？必须调用
consumer.CommitOffsets()，否则重启后可能重复消费或跳过消息 - 多分区 Topic 下，单个消费者只能消费部分分区，要靠消费者组自动再平衡
Redis Pub/Sub 适合什么场景
Redis Pub/Sub 是纯内存广播，无持久化、无 ACK、无重试，连接断开即丢失消息。但它启动快、零依赖、延迟低，适合“通知型”而非“任务型”场景。
典型适用：配置热更新通知（如 feature flag 变更）、在线状态同步（用户上线/下线广播）、缓存失效指令（PUBLISH cache:invalidate:user:123 ""）。
- 别用它发订单创建事件——万一 consumer 挂了 5 秒，这条消息就永久消失
- 订阅方要用
redis.PubSubConn.Subscribe()，不是普通GET/SET客户端 - 频道名（channel name）区分大小写，且不支持通配符订阅（
redis-cli支持PSUBSCRIBE，但 Go 客户端需确认是否启用）
实际部署时最容易被忽略的，是消息语义与业务一致性的对齐：NATS 的“最多一次”、Kafka 的“至少一次”、Redis Pub/Sub 的“尽力而为”，每种模型都要求业务代码做不同级别的幂等或补偿处理。选错中间件不是性能问题，而是数据一致性风险。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
