直接用 channel + map 实现 Pub/Sub 易崩，因 channel 不支持广播、易死锁或漏事件，且 subscriber 崩溃后 publisher 仍发数据导致 panic；应引入 dispatcher goroutine 和 sync.Map 管理订阅，用泛型约束 payload 类型防类型擦除。
为什么不用第三方库，直接用 channel + map 实现 Pub/Sub 容易崩
因为 Go 的 channel 本身不支持一对多广播，硬塞一个 chan interface{} 给所有 subscriber，要么得加锁遍历发，要么用 select 非阻塞轮询——前者写错锁范围就死锁，后者漏事件是常态。更麻烦的是，subscriber 挂了（比如 goroutine panic 或提前退出），没人通知 publisher，channel 还在往里塞数据，迟早 panic: send on closed channel。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- publisher 不直接操作 subscriber 的
chan，改用中间层：每个 subscriber 持有独立的chan interface{}，由一个统一的 dispatcher goroutine 负责转发 - 用
sync.Map存 subscriber 列表，key 是类型安全的topic string，value 是*sync.Map（存id → chan映射），避免读写竞争 - 每次
Subscribe返回一个unsubscribe func()，内部调用delete并 close 对应 channel，防止 goroutine 泄漏
Subscribe 和 Publish 的参数设计怎么避开类型擦除陷阱
如果所有事件都走 interface{}，运行时类型断言失败就是静默丢事件；用泛型又没法让不同 topic 共享同一套 dispatcher。折中方案是：topic 是字符串，但 payload 强制为具体类型，靠编译期约束。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 定义
type Topic string，不是string，防止误传任意字符串 Subscribe[T any](topic Topic, ch chan —— channel 类型绑定 payload，编译器会检查 <code>ch是否能接收T-
Publish(topic Topic, v interface{})不行；必须拆成Publish[T any](topic Topic, v T)，否则无法做类型校验 - dispatcher 内部用
any中转，但只在确定目标 channel 类型匹配时才ch ，否则跳过（可加日志）
goroutine 泄漏最常发生在哪几个环节
90% 的泄漏不是因为没关 channel，而是 dispatcher goroutine 卡在向已满或已关闭的 subscriber channel 发送数据，且没有超时或 select default 保护。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- subscriber channel 必须带缓冲：
make(chan Event, 16)，大小根据事件吞吐预估，太小容易阻塞，太大吃内存 - dispatcher 发送时用
select { case ch ，跳过无法立即送达的 subscriber，不等不卡 - 每个 subscriber goroutine 自己处理
for v := range ch，收到nil或closed就退出，别用for { v, ok := ——这写法在 channel 关闭后仍可能多跑一次 - 测试时用
runtime.NumGoroutine()对比订阅/退订前后，确认无残留
要不要支持通配符 topic（比如 "user.*"）
要，但别在核心 dispatch 路径里做字符串匹配。高频 publish 场景下，strings.HasPrefix 或正则会拖慢整个事件流，而且通配逻辑和精确匹配语义不同，混在一起难 debug。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 通配订阅单独走另一套注册表：
sync.Map[string]map[Topic]struct{}，key 是 pattern，value 是匹配到的 topic 集合 - publish 时先查精确匹配，再查 pattern 表（只查一次），把匹配到的 topic 批量加入待发列表
- pattern 解析放在
SubscribeWildcard里做，不是每次 publish 都 parse - 不支持嵌套通配（如
"user.**.updated"），避免回溯爆炸；只接受*和**（后者需明确约定语义）
真正难的不是代码怎么写，是决定哪些 topic 必须精确、哪些允许模糊——这取决于业务对事件投递语义的要求。比如状态变更必须精准送达，而监控指标可以宽松匹配。没想清楚这点，后面加再多优化都白搭。
