跨服务事件总线必须用NATS/Kafka等中间件，不能用chan或本地EventBus，因其无法序列化、无重试/持久化/跨节点路由能力，硬用会导致事件静默丢失和goroutine泄漏。
跨服务事件总线不能靠 chan interface{} 或本地 EventBus 实现——它本质是分布式通信问题，不是并发控制问题。硬用内存总线跨进程，轻则丢事件、重则 goroutine 泄漏到数万级，监控里看到 runtime.NumGoroutine() 持续上涨就是信号。
为什么本地 EventBus 无法跨服务
本地总线（如用 map[string][]chan interface{} + sync.RWMutex）只在单进程内有效。一旦服务拆分为多个进程（比如 user-service 和 order-service 分别部署），chan 就彻底失效：channel 是进程内引用，无法序列化、无法网络传输，更不支持重试、持久化或跨节点路由。
- 现象：调用
Publish("order.created", event)后，另一台机器上的 subscriber 完全收不到——没报错，只是静默丢失 - 根本原因：Go 的
chan不是“消息句柄”，而是运行时对象，生命周期绑定 goroutine 和堆内存 - 误用后果：你以为在解耦，实际把服务间依赖从编译期转移到了部署拓扑上（比如必须同机部署才能通），反而更脆弱
必须选型消息中间件而非自研网络层
生产环境跨服务事件传递，应直接基于成熟消息中间件构建，而不是自己封装 TCP/HTTP 事件转发。自研网络层会重复造轮子，且难以解决 ACK、offset 提交、分区再平衡等核心问题。
- 推荐组合：
Kafka（高吞吐+持久化+多订阅者）、NATS JetStream（轻量+内置流式语义）、Redis Streams（已有 Redis 且量不大时快速落地） - 避免踩坑：
RabbitMQ虽然成熟，但 Go 生态 client（如streadway/amqp）对自动 reconnect 和 channel 复用支持较弱，容易因连接断开导致事件堆积或丢失 - 关键配置项：
acks=all（Kafka）、ack_wait（NATS）、GROUP名必须唯一且带服务标识（如inventory-consumer-v2），否则 offset 错乱
Go 客户端集成的三个实操要点
用 segmentio/kafka-go 或 nats-io/nats.go 时，真正影响稳定性的不是发送逻辑，而是消费端的错误处理与资源生命周期管理。
立即学习“go语言免费学习笔记（深入）”；
- 消费循环必须包
recover()+log.Error：一个 handler panic 会导致整个for msg := range ch循环退出，后续消息永远卡住 - 每条消息处理前加
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)：防止 DB 查询或 HTTP 调用挂死，阻塞整个 partition 消费 -
Subscribe返回的Consumer对象必须显式调用Close()：否则连接泄漏，Kafka broker 端会累积大量 idle connection，触发TooManyRequests - 示例片段（Kafka）：
for { msg, err := reader.ReadMessage(ctx) if err != nil { log.Warn("read message failed", "err", err) continue // 别 return，否则消费停止 } go func(m kafka.Message) { defer func() { if r := recover(); r != nil { log.Error("handler panic", "msg", string(m.Value), "panic", r) } }() handleOrderCreated(m.Value) }(msg) }
事件结构定义与版本兼容性陷阱
跨服务事件不是临时 struct，而是契约。字段增删、类型变更都会导致下游解析失败，且 Go 没有 schema registry 原生支持，必须人工约束。
- 所有事件 struct 必须定义在独立
event/包中，由发布方和订阅方共同import—— 避免各自定义同名 struct 导致 JSON 反序列化字段错位 - 禁止用
interface{}作为事件 payload：JSON unmarshal 到空接口后，event.Data.(map[string]interface{})这类断言极易 panic，且无法做字段存在性校验 - 新增可选字段必须加
json:",omitempty"，并确保下游 handler 对字段缺失有 fallback 逻辑（比如默认值或跳过处理） - 重大变更（如删除必填字段）必须升级 topic 名，例如从
order.created.v1改为order.created.v2，旧消费者继续读 v1，新消费者读 v2
最常被忽略的点是：事件投递成功 ≠ 业务成功。即使 Kafka 返回 Success，下游 handler 仍可能因数据异常、DB 冲突、幂等键缺失而失败。真正的可靠性不在总线，而在消费端的重试策略、死信落盘和人工干预入口——这些没法靠 “换个总线实现” 解决。
