直接用chan适用于进程内小规模通信，如小模块间状态通知、配置热更新、测试mock等场景；跨服务或需持久化时必须使用NATS/Kafka等中间件。
Go 里没有“开箱即用”的消息总线组件，直接用 chan 或自研 EventBus 都可能翻车——关键看场景：进程内小规模通信，chan 最快最稳；跨服务或需持久化，必须上 NATS/Kafka。
什么时候该直接用 chan 而不是写 EventBus
小模块间状态通知、配置热更新、测试 mock 这类场景，chan 是最优解，干净、无依赖、零调度开销。
- 用
make(chan Event, 16)带缓冲 channel，容量按峰值吞吐预估：太小会阻塞 sender，太大吃内存 - 别在
select { case ch 外裸写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 单节点没问题，但一上生产，缺这几项就等于裸奔：
- 连接必须显式设重连：
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"），字段增删改时靠它做兼容 - 别把
nats://user:pass@host:port这种带密码的 URL 写死在代码里，改用nats.UserCredentials("user.creds")加载凭证文件
真正难的不是“怎么写”，而是“怎么选”：多数人卡在该用 chan 还是 EventBus 的边界上——这个边界由事件规模、顺序要求、错误容忍度共同决定，而不是由“看起来更高级”决定。
