用 sync.Map 做 Pub/Sub 易出问题：无法原子发布、不保序、取消订阅难清理；闭包或 channel 可能被 GC 提前回收；并发更新订阅列表会覆盖；无 panic 或满 channel 时的自动剔除机制。
Go 里用 sync.Map 做简单 Pub/Sub 容易出什么问题？
sync.Map 确实能存 topic → subscriber 列表，但不是为 Pub/Sub 设计的。它不提供原子性发布、不保证订阅顺序、也不支持取消订阅时的安全清理。
- 订阅者是函数值或 channel，存进
sync.Map后，如果没额外引用管理，GC 可能提前回收闭包或关闭 channel，导致静默丢消息 - 多个 goroutine 同时
Load+Store更新订阅列表时，可能覆盖彼此（sync.Map的LoadOrStore不适用于 slice 类型的追加操作） - 没有生命周期钩子，无法在订阅者 panic 或 channel 满了时自动剔除
别硬套 sync.Map 存 subscriber 列表；它适合读多写少的键值缓存，不适合状态协同。
用 chan 实现基础 Pub/Sub 时，为什么一发多收总漏消息？
因为 Go 的 channel 是点对点通信原语，直接把同一个 chan 给多个 subscriber，只会有一个 goroutine 收到消息（除非用缓冲且容量够大，但这不可控）。
正确做法是：每个 subscriber 拿到自己的专属 channel，由一个中心 goroutine 负责广播：
立即学习“go语言免费学习笔记（深入）”；
- 创建 topic 时，维护一个
map[string][]chan interface{}，值是 subscriber 的接收 channel 切片 - 发布时遍历该切片，用
select+default非阻塞发送，避免某个慢 consumer 拖垮整体 - 订阅 channel 应设缓冲（如
make(chan interface{}, 16)），否则一旦消费者卡住，下一次 publish 就会阻塞或丢弃
示例关键片段：
for _, ch := range subs {
select {
case ch <- msg:
default:
// 消费者太慢，跳过，不阻塞发布
}
}要不要用第三方库比如 github.com/ThreeDotsLabs/watermill 或 github.com/google/wire？
watermill 是重型消息框架，面向 Kafka / RabbitMQ 场景，本地内存 Pub/Sub 属于杀鸡用牛刀——启动慢、配置绕、trace 日志泛滥，还强制你写 handler 接口和消息结构体。
wire 是依赖注入工具，跟 Pub/Sub 完全无关，搜错关键词了。
真正轻量可嵌入的选择只有两个：
- 自己写（200 行内搞定，控制力强，无隐藏 goroutine）
- 用
github.com/bsm/redeem（专注内存事件总线，支持 topic 层级匹配、上下文取消、优雅关闭）
如果项目已用 go.uber.org/zap 或 context 传参，自己实现时记得把 context.Context 透传进每个 subscriber goroutine，不然 cancel 信号进不来。
订阅者 panic 了，整个发布流程会崩吗？
会。默认情况下，如果广播循环里某个 subscriber 的 handler 函数 panic，整个 for 循环就终止，后续 subscriber 再也收不到这次发布的消息。
必须显式 recover：
- 在每轮发送前起一个匿名 goroutine 包裹 handler 调用
- 用
defer+recover()捕获 panic，只打日志，不传播 - 不要试图“重试”失败的 subscriber，它可能已处于不可恢复状态
go func(ch chan<- interface{}, msg interface{}) {
defer func() {
if r := recover(); r != nil {
log.Printf("subscriber panic: %v", r)
}
}()
ch <- msg
}(subCh, msg)复杂点在于：recover 只能捕获当前 goroutine 的 panic，所以每个 subscriber 必须独立 goroutine 运行；这点容易被忽略，结果一 panic 全挂。
