结论：用 sync.Map + chan 按 topic 动态管理独立通道更可控、易伸缩，避免 goroutine 泄漏和 channel 关闭竞争；全局 channel 会导致订阅不精确、背压传导、扩容错配，已引发过 17 个 topic 积压超 200 万的事故。
直接说结论：用 sync.Map + chan 按 topic 动态管理独立通道，比全局单 channel 或固定 slice 更可控、更易伸缩，也避免了 goroutine 泄漏和 channel 关闭竞争问题。
为什么不能用一个全局 channel 做所有 topic 的分发
全局 channel 在多 topic 场景下会立刻暴露三个硬伤：
- 消费者无法按 topic 订阅，只能全量接收再做字符串匹配，CPU 白耗在
if msg.Topic == "user.login"上 - 某个慢消费者（比如处理 “payment” topic 的逻辑卡住）会拖垮所有其他 topic 的消费进度，背压传导无隔离
- 扩容时无法单独扩某个热 topic，只能整体加 worker，资源错配严重
实际线上见过因一个异常 topic 消费阻塞，导致 17 个其他业务 topic 积压超 200 万条的事故。这不是理论风险，是高频发生的问题。
如何用 sync.Map 动态管理 topic-channel 映射
sync.Map 是唯一适合运行时动态增删 topic 的并发安全 map；但注意它不支持遍历，所以不能靠 range 清理失效 channel，必须配合显式生命周期控制。
立即学习“go语言免费学习笔记（深入）”；
关键设计点：
- 每个 topic 对应一个带缓冲的
chan Message，缓冲大小按该 topic 的平均吞吐预估，例如make(chan Message, 1024) - channel 创建后存入
sync.Map，key 是topic string，value 是*chan Message（指针，避免 copy） - 消费者启动时调用
Subscribe(topic)获取对应 channel，退出前调用Unsubscribe(topic)触发清理逻辑 - 不要在
sync.Map.Load后直接 send/receive —— 必须先判空，因为 channel 可能已被关闭且未及时从 map 中移除
示例判断逻辑：
if chPtr, ok := topicChans.Load(topic); ok {
ch := *chPtr
select {
case ch <- msg:
default:
// 缓冲满，可丢弃或走降级路径
}
}
如何安全关闭单个 topic 的 channel 而不 panic
Go channel 关闭后再次 send 会 panic，而 sync.Map 里存的是指针，多个 goroutine 可能同时操作同一 channel。必须引入原子状态标记。
推荐做法：
- 为每个 topic 维护一个
int32状态变量，用atomic.CompareAndSwapInt32控制关闭流程 - 关闭前先置状态为
CLOSING，再 close channel，最后从sync.Map中 Delete - 所有 send 操作都需先
atomic.LoadInt32(&state)判断是否已关闭，避免向已关闭 channel 写入 - consumer 侧用
select { case 配合超时检测 channel 是否已失效，而不是依赖 <code>range（range 在 close 后会自动退出，但无法区分是正常关还是异常关）
这个细节被大量开源项目忽略，结果就是上线后偶发 panic，日志里只显示 send on closed channel，却找不到谁关的、什么时候关的。
消息结构体要不要用 sync.Pool 复用
要，但仅限于固定字段、生命周期明确的场景。比如 type Message struct { Topic string; Payload []byte; Timestamp int64 } 这种结构体，sync.Pool 能减少 GC 压力；但如果 Payload 是大 buffer 或含指针（如嵌套 map），复用反而导致内存泄漏或数据污染。
实操建议：
- 定义
var msgPool = sync.Pool{New: func() interface{} { return &Message{} }} - 每次从 pool 取出后，**必须重置所有字段**，尤其是
Payload要msg.Payload = msg.Payload[:0] - 处理完消息后，只在确定不再引用 Payload 底层数组时才
msgPool.Put(msg)，否则可能被后续 goroutine 误读旧数据
这个 reset 步骤漏掉一次，就可能引发跨 topic 的 payload 混淆 —— 某个 user.login 消息里出现 payment 的银行卡号，线上故障定位成本极高。
