直接用 chan interface{} 做 Pub/Sub 会卡死，因 Go channel 默认同步，无接收者时发送阻塞；缓冲 channel 溢出仍阻塞，且无法动态管理订阅者；正确做法是用 select+default 非阻塞发送或 goroutine 封装。
为什么直接用 chan interface{} 做 Pub/Sub 会卡死
因为 Go 的 channel 默认是同步的，没 goroutine 接收时，send 操作会阻塞。Pub/Sub 场景下发布者不关心谁在听、有没有人听，卡住就违背了事件驱动的初衷。
- 别用无缓冲 channel 当事件总线——哪怕只有一订阅者，也容易因处理慢导致发布端 hang 住
- 缓冲 channel 看似能缓解，但容量固定，溢出后还是阻塞；且无法动态增减订阅者
- 真正要的是“发完就返回”，所以必须把发送逻辑挪进 goroutine，但得小心 goroutine 泄漏
正确做法：封装一个 Publisher 类型，内部用 select + default 实现非阻塞发送，或统一用 go func() { ch 并配超时/取消控制。
sync.Map 存订阅者列表比 map + mutex 更省心？
不是更省心，是更容易错。虽然 sync.Map 支持并发读写，但它不支持遍历中删除——而 Pub/Sub 的典型需求是：订阅者退出时主动 Unsubscribe，或监听到 channel 关闭后自动清理。
-
sync.Map.Range是快照式遍历，期间其他 goroutine 删除 key，不会反映在本次遍历中，导致消息误发 - 真正安全的做法仍是
map[subscriberID]*chan Event+sync.RWMutex，读多写少场景下性能足够 - 如果用
sync.Map，必须配合额外的清理机制（如每个 subscriber 启一个 goroutine 监听donechannel），反而增加复杂度
示例清理逻辑：
go func(ch <-chan struct{}) { <-ch; mu.Lock(); delete(subs, id); mu.Unlock() }(sub.done)
立即学习“go语言免费学习笔记（深入）”；
如何避免 goroutine 泄漏导致内存持续上涨
最常见泄漏点：订阅者 chan 被关闭后，发布端还在往里发；或者订阅者已退出，但 publisher 还保留着它的 channel 引用。
- 每个 subscriber 应提供
done chan struct{}，publisher 在select中监听它，一旦关闭就从 map 中移除 - 发布循环里别直接
ch ，改用 <code>select { case ch 防止因接收方卡住而堆积 goroutine - 不要用
time.After做发送超时——它会持续运行直到超时，应改用context.WithTimeout或手动time.NewTimer+Stop()
关键判断：只要看到 go func() { ... }() 出现在循环里，就要立刻检查是否有对应的退出路径和资源回收。
要不要给事件加类型字段（比如 EventType string）
要，但别用字符串硬编码。字符串易拼错、难维护、无法被编译器检查。
- 定义
type EventType string常量，所有事件类型从此枚举取值，例如EventUserCreated EventType = "user.created" - 订阅时支持按前缀匹配（如
"user."），这时需要把EventType当成可切分的路径，而非单纯标识符 - 如果用反射或 interface{} 做泛型事件，务必在发送前做类型断言或使用
encoding/json.RawMessage延迟解析，否则反序列化失败会导致静默丢事件
一个容易被忽略的细节：日志里打印事件类型时，别直接 fmt.Printf("%v", evt.Type)，要用 string(evt.Type)，否则输出带包名的全限定名，干扰排查。
