用 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 负责广播：
- 创建 topic 时，维护一个
map[string][]chan interface{}，值是 subscriber 的接收 channel 切片 - 发布时遍历该切片，用
select+default非阻塞发送，避免某个慢 consumer 拖垮整体 - 订阅 channel 应设缓冲（如
make(chan interface{}, 16)），否则一旦消费者卡住，下一次 publish 就会阻塞或丢弃
示例关键片段：
for _, ch := range subs {
select {
case ch <h3>要不要用第三方库比如 <code>github.com/ThreeDotsLabs/watermill</code> 或 <code>github.com/google/wire</code>？</h3><p><code>watermill</code> 是重型消息框架，面向 Kafka / RabbitMQ 场景，本地内存 Pub/Sub 属于杀鸡用牛刀——启动慢、配置绕、trace 日志泛滥，还强制你写 handler 接口和消息结构体。</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/gongju/2525" title="Go语言（Golang）1.26.0"><img
src="https://img.php.cn/upload/manual/001/589/237/6a6adeed24a4a355.png" alt="Go语言（Golang）1.26.0" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/gongju/2525" title="Go语言（Golang）1.26.0" class="overflowclass">Go语言（Golang）1.26.0</a>
<p class="overflowclass">Go语言（Golang）1.26.0版本官方下载，版本号 1.26.0，适合旧项目维护、兼容性测试和指定版本开发环境搭建。</p>
</div>
<a rel="nofollow" href="/xiazai/gongju/2525" title="Go语言（Golang）1.26.0" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div><p><code>wire</code> 是依赖注入工具，跟 Pub/Sub 完全无关，搜错关键词了。</p><p>真正轻量可嵌入的选择只有两个：</p>
- 自己写（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<p>复杂点在于：recover 只能捕获当前 goroutine 的 panic，所以每个 subscriber 必须独立 goroutine 运行；这点容易被忽略，结果一 panic 全挂。</p>
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
