用 map[string][]chan interface{} 实现轻量级事件总线，够用但别硬扛高并发
直接上结论：中小型服务内部解耦，用原生 channel + map 自研 Pub/Sub 完全可行；但一旦订阅者超 50 个、消息频率超 100 QPS，就得警惕锁竞争和 goroutine 泄漏。
核心结构就是 map[string][]chan interface{} —— 主题名作 key，每个订阅者独占一个带缓冲的 chan（比如 make(chan interface{}, 10)）。发布时遍历 slice，用 select { case ch 非阻塞投递，避免某个慢订阅者拖垮全局。
- 别用无缓冲
chan：一卡全卡，Publish直接阻塞 - 别在
Subscribe里启动消费 goroutine：Broker 只负责分发，谁订阅谁自己开 goroutine 读通道 - 用
sync.RWMutex保护 map 读写，或直接换sync.Map（Go 1.9+），后者在读多写少场景下性能更稳
Publish 必须异步且带背压处理，否则上线就报警
常见错误是把 Publish 写成同步广播：for _, ch := range subs[topic] { ch 。一旦某个 <code>ch 满了或消费者卡住，整个调用就 hang 住，HTTP 接口超时、定时任务失败全跟着来。
正确做法是为每次发布启动独立 goroutine，并对每个订阅通道做非阻塞尝试：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
go func() {
for _, ch := range eb.subs[topic] {
select {
case ch <- msg:
default:
// 记 log 或打 metric，说明该订阅者已积压
}
}
}()- 不加
go：同步阻塞，违反 Pub/Sub 异步本质 - 不加
select + default：等同于直接ch ，退化为点对点通信 - 不记录
default分支：线上出问题时完全无法定位是哪个模块消费不过来
主题命名必须带业务域前缀，"user.registered" 比 "registered" 少一半联调时间
看似只是字符串约定，实则影响权限控制、日志追踪、监控切片和未来对接 Kafka/NATS 的平滑度。见过太多团队初期用 "login"、"pay" 这类裸名，后期加风控模块要监听所有支付事件，结果发现订单、退款、充值全混在一个 topic 下，改又不敢改，只能套壳转发。
- 强制格式：
"{domain}.{action}"，例如"order.created"、"payment.refunded" - 禁止用动词过去式以外的形态（如不用
"order_create"或"onOrderCreate"） - 消息体必须是结构体，禁用
interface{}：接收方要msg.(UserRegisteredEvent)断言？那等于没类型安全
别在订阅回调里做 DB/HTTP 调用，goroutine 泄漏比内存泄漏更难查
典型反模式：订阅 "user.registered" 后，直接在 for range mailCh 循环里调 sendWelcomeEmail()。这个函数如果因网络抖动卡住 5 秒，而你开了 10 个 worker，瞬间就堆积 50 个卡住的 goroutine —— pprof/goroutines 一眼看到几百个 net/http 栈，却找不到源头。
真正该做的，是把耗时操作扔进 worker pool 或发到异步任务队列（如 asynq）：
- 订阅端只做「接收 → 解包 → 投递」三件事
- 用
context.WithTimeout包裹任何外部调用，防止无限等待 - 每个订阅
chan必须有明确生命周期：由使用者控制启停，Broker 不负责关闭通道
最常被忽略的一点：没有取消订阅机制的 EventBus，跑一周后 map 里堆满已退出服务的 channel，内存只增不减——Subscribe 返回一个 func()，调它时从 map 里删掉对应项，这事得手动做，runtime 不会帮你扫。
