不能裸用chan interface{}做事件总线，因其导致类型擦除引发运行时panic、并发写未加锁map崩溃、单个handler阻塞拖垮全局；应为每个topic分配带缓冲的typed channel并用sync.rwmutex保护订阅映射。
为什么别裸用 chan interface{} 做事件总线
直接声明 var bus = make(chan interface{}, 10) 然后往里塞各种事件，看似简单，实际会立刻踩三个坑：类型擦除导致编译期零校验，运行时 type assertion 失败就 panic；多个 goroutine 并发写入未加锁的订阅 map 会直接 crash；更隐蔽的是——一个 handler 处理慢或 panic，整个 for range bus 循环就卡死，其他监听器全被拖垮。
真正可用的起点是：每个事件主题（topic）对应一个独立的、带缓冲的 channel，比如 user.created → make(chan *UserCreatedEvent, 16)，再用 sync.RWMutex 保护 map[string][]chan 的读写。别图省事拼字符串当 key，也别让所有事件挤进同一个 channel。
如何安全注册和注销监听器
监听器生命周期失控是 goroutine 泄漏最常见原因。常见错误包括：订阅后没提供取消函数；在 handler 里 defer close(channel)，结果 context 先 cancel 导致 double-close panic；用闭包函数字面量当 map key，每次调用地址不同，根本删不掉旧监听器。
- 订阅方法必须返回
func()取消函数，内部做两件事：从 map 中删除该 channel、显式close(ch) - key 必须稳定可比——用字符串常量（如
UserRegisteredTopic）或字段全为基本类型的 struct - 测试时用
runtime.NumGoroutine()断言，验证注销后 goroutine 数回落
handler 怎么防 panic 和超时拖垮整个总线
handler 里调一次没设 timeout 的 HTTP 请求，或者没 recover 的 panic，会让整个事件循环退出或卡住——这不是“异常没捕获”的常规问题，而是事件驱动里最致命的单点故障。
每个 handler 必须运行在独立 goroutine，并包裹标准防护：
- 开头检查
ctx.Err() != nil，用context.WithTimeout(ctx, 5*time.Second)控制下游调用 - 外层
defer func() { if r := recover(); r != nil { log.Printf("handler panic: %v", r) } }() - 函数签名统一为
func(context.Context, Event) error，便于后续加日志、重试中间件
什么时候该放弃自建总线，直接上 Kafka/NATS
进程内 channel 总线只适合低频、同进程、无需持久化与重试的场景。一旦出现以下任一情况，就得切到消息中间件：
- 需要跨服务通信（channel 无法穿透网络边界）
- 要求事件至少一次投递（channel 丢事件无感知，Kafka 可手动 commit offset）
- 消费者处理失败需进死信队列（自建总线得自己实现 fallback 存盘+定时重试）
- 事件量级超过每秒几百条，且对顺序/分区有要求
Go 生态里，segmentio/kafka-go 和 nats.go 是生产首选；别为了“轻量”硬扛，事件可靠性出问题时，debug 成本远高于初期多引入一个库。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
