应直接用 chan 的场景是小模块间状态通知、配置热更新、测试 mock；此时用 make(chan Event, 16) 带缓冲 channel，容量需按峰值吞吐预估，过小致阻塞、过大耗内存。
Go 里没有“开箱即用”的消息总线组件，得按场景选型：进程内用 chan 或轻量 EventBus，跨服务必须上 NATS/Kafka；硬套一个通用库反而容易踩并发、丢事件、难调试。
什么时候该直接用 chan 而不是写 EventBus
小模块间状态通知、配置热更新、测试 mock 场景，chan 最干净：
- 用
make(chan Event, 16)带缓冲 channel，大小按峰值吞吐预估；太小会阻塞 sender，太大吃内存 - 别在
select { case ch 外裸写 <code>ch ，否则 receiver 挂了就卡死 - 多个 goroutine 往同一 channel 发送时，顺序不保证——如果 order_id 必须严格有序，得加锁或串行化
- channel 关闭后继续 send 会 panic，receiver 需用
event, ok := 判断是否已关闭
自研内存 EventBus 必须处理的三个并发陷阱
用 map[string][]func(interface{}) + sync.RWMutex 是最稳的起点，但以下点一错就崩：
-
handlers字段绝不能导出，否则外部绕过锁直接改 map，必报fatal error: concurrent map read and map write - 注册/注销都得用
mu.Lock()，不能一个加锁一个不加；读事件分发时用mu.RLock() - 遍历 handler 切片时，不能边 loop 边 append 新 handler——要先
copy出副本再遍历，否则可能 panic 或漏调 - handler 内 panic 会中断整个通知流，每个调用必须包一层
recover()，且 log 错误，别静默吞掉
NATS JetStream 生产环境连接和发布不能省的配置
本地跑 nats-server 单节点没问题，但一上生产，缺这几项就等于裸奔：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 连接必须显式设重连：
nats.MaxReconnects(60)、nats.ReconnectWait(2*time.Second)、nats.ReconnectJitter(100*time.Millisecond, time.Second) - 启用 JetStream 后，
js, err := jetstream.New(nc)要立刻执行，不能等第一次js.Publish()才初始化，否则 panic - 发布消息必须带
nats.WithMsgID("order-123")，否则流配置的Duplicates: 2*time.Minute不生效 - 订阅要用
nats.DeliverPolicy(nats.DeliverAll)，否则消费者重启后收不到断连期间的消息
事件结构体定义中容易被忽略的契约细节
结构体不是随便写个 type Event struct{ Data interface{} } 就完事，这几个字段缺一不可：
- 必须有
Type string `json:"type"`字段，否则消费者无法路由到对应 handler - 必须有
Version string `json:"version"`（如"v1"），字段增删改时靠它做兼容判断 - 时间戳用
CreatedAt time.Time `json:"created_at,string"`，不用字符串字段，避免解析失败 - 业务主键（如
OrderID int64）要导出并加 JSON 标签，幂等逻辑和 Kafka 分区都依赖它 - 别把
context.Context塞进事件结构体——它生命周期短、不可序列化，真需要超时控制，应单独传参或封装进 handler 闭包
真正卡住上线的往往不是“怎么发”，而是“怎么确保每条都处理对”：NATS 不保证 exactly-once，Kafka 的 offset 提交时机不对就会丢数据，自研总线里 recover 没包全会导致后续监听者永远收不到事件——这些点不手敲几遍，光看文档没用。
