推荐用 sync.Map + 独立 chan + context.Context 实现内存级 Pub/Sub：sync.Map 避免并发写 panic 和迭代器失效，Range 快照语义确保发布一致性；须封装 value 为 struct 并避免在 Range 中 Load/Store；每个订阅绑定 context 防 goroutine 与 channel 泄漏。
直接用 sync.Map + 独立 chan + context.Context 控制生命周期，是当前 Go 生产环境里最可控、性能足够且不易泄漏的内存级 Pub/Sub 实现方式。别碰裸 interface{}、别共享 channel、别手动关 channel —— 这三件事踩中任一，两周后服务内存和 goroutine 数就明显上涨。
为什么不能直接用 map[string][]chan interface{}
并发写会 panic：fatal error: concurrent map writes；遍历时删元素会触发迭代器失效；读多写少场景下，sync.RWMutex 争抢严重，尤其 WebSocket 频繁进出时，锁成为瓶颈。而 sync.Map 原生支持原子 Load/Store/Delete，且 Range 是快照语义——发布时只通知“此刻已注册”的订阅者，符合预期。
-
sync.Map的 value 必须是统一类型，推荐封装为struct{ id string; ch chan Event }，避免存裸函数或未导出字段 - 别在
Range回调里调Load/Store，会 panic；需修改请先LoadAll拷贝快照再处理 - topic 极少（如固定 3–5 个）且注册集中在启动期，用
map + sync.RWMutex更轻量
如何防止 goroutine 和 channel 泄漏
泄漏主因是：订阅者退出后，channel 还挂在 sync.Map 里，发布者继续往里发，要么 panic：send on closed channel，要么阻塞在 select { case ch 直到进程重启。
- 每个订阅必须绑定
context.Context，Subscribe返回chan Event和context.CancelFunc - 消费者 goroutine 必须用
for { select { case msg := ，不可忽略 <code>ctx.Done() -
Unsubscribe内部要同步完成三件事：从sync.Map删除条目 +close(ch)+ 调用cancel() - 别在 defer 里关 channel —— 若 context 先 cancel，defer 还会执行，导致 double-close panic
发布时如何避免阻塞和 panic
一个慢订阅者卡住整个发布流程，是高频事故。关键不是“等它”，而是“跳过它”并确保不崩。
立即学习“go语言免费学习笔记（深入）”；
- 发送必须用
select { case ch ，非阻塞；不要用 <code>ch 或带超时的 <code>select { case ch - 每个订阅回调需包
defer func() { recover() }()，否则一个 panic 会让后续所有订阅者收不到消息 - 消息体推荐用
type Event struct { Topic string; Payload interface{} }，而非裸interface{}，避免消费端类型断言失败静默丢数据 - channel 缓冲区设为
make(chan Event, 16)，太小易丢，太大增 GC 压力；勿用无缓冲 channel
取消订阅为什么经常失效
调了 Unsubscribe("user.created", handler)，但之后仍收到消息 —— 大概率是靠函数值比较移除，而 Go 中闭包、方法值、匿名函数即使逻辑相同，== 也返回 false。
- 必须给每个订阅分配唯一
id（如uuid.NewString()），存进sync.Map的 value 结构体里 -
Unsubscribe参数应为topic string, id string，而不是topic string, ch chan Event - 若坚持用 channel 地址做 key，请转成
uintptr(unsafe.Pointer(&ch))，但可读性差且难调试 - 测试时务必覆盖“订阅后立即取消，再 publish”的时序，用
sync.WaitGroup或time.Sleep控制节奏，否则容易漏掉 race
真正难的不是写出能跑通的代码，而是让每个 Subscribe 调用都附带明确的生命周期边界，以及每次 Publish 都默认接受“部分失败”。内存级 Pub/Sub 本就不承诺送达，它的价值在于解耦和响应速度，而不是可靠性 —— 要可靠，该上 Redis 或 Kafka。
