用 channel 做事件总线易卡死，因其本质是点对点管道，不支持一对多广播：无缓冲时发送阻塞，有缓冲时满则丢事件，且无法动态增删监听者，导致 deadlock 或事件静默。
为什么用 channel 做事件总线容易卡死
channel 本身不是事件总线，它只是同步/异步通信的管道。直接拿 chan interface{} 当事件广播用，一发多收场景下立刻出问题：要么阻塞发送方（无缓冲且没人读），要么丢事件（有缓冲但满），更麻烦的是没法动态增减监听者。
常见错误现象：fatal error: all goroutines are asleep - deadlock，或者某次发布后只有第一个 listener 收到，其余静默。
- 别用
chan Event直接暴露给业务层，它不具备“一对多”分发能力 - 如果真要用 channel，只在内部做“生产者 → 路由器”这单跳，后续靠 goroutine + for-range 分发到各 listener 的私有 channel
- 注意关闭时机：不能随便 close 全局事件 channel，否则所有 range 会退出；应靠 context 或显式 stop signal 控制生命周期
Interface 定义事件处理器时，方法签名怎么选
事件驱动里最常踩的坑是把 Handle(Event) 设计成阻塞调用 —— 一个慢 handler 拖垮整个事件流。接口设计本质是约定调度契约，不是功能封装。
典型错误：定义 type EventHandler interface { Handle(e Event) error }，然后在循环里同步调用每个 handler.Handle()。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 推荐签名是
Handle(ctx context.Context, e Event)，强制 caller 传入超时/取消控制 - 如果 handler 可能异步执行（比如写 DB、发 HTTP），接口里就别返回 error，改用 callback 或 channel 回传结果，避免阻塞主事件循环
- 别让接口带状态（如
SetLogger()），事件处理器应该是无状态的；状态放实现 struct 里，接口只管“收到事件后做什么”
Channel + Interface 组合落地时，如何避免 goroutine 泄漏
组合模式下泄漏高发点不在 channel 本身，而在监听器注册后没注销、或 handler 启动的 goroutine 没随事件生命周期结束。
使用场景：服务启动时注册一批 handler，运行中动态启停某个模块的监听能力。
- 每个 handler 应持有自己的
done chan struct{}，在Stop()方法里 close 它，并在 goroutine 中 select 等待该信号 - 注册表（map）里存的不是裸 handler 接口，而是包装结构体，含
handler EventHandler和cancel func()（来自 context.WithCancel） - 别用
time.AfterFunc做延迟清理，它不感知 context；统一用time.AfterFunc+select { case
要不要为不同事件类型建独立 channel
按事件类型拆 channel（如 userCreatedCh, orderPaidCh）看似清晰，实际增加维护成本和路由复杂度，多数情况下没必要。
性能影响明显：100 种事件开 100 个 channel，goroutine 调度开销上升，内存占用翻倍（每个 unbuffered channel 约 24B，buffered 更多）。
- 优先用单个
chan Event，靠 type switch 或 interface 断言区分处理逻辑 - 只有当某类事件量级远超其他（比如日志事件 QPS 是业务事件 100 倍），才考虑单独 channel + 独立 worker pool
- 兼容性提示：如果未来要对接外部系统（如 Kafka），统一 channel 结构更易做协议适配，避免每个事件类型写一套序列化逻辑
真正难的是事件幂等性、顺序保证、失败重试策略——这些跟 channel 和 interface 关系不大，但一旦上线就会暴露。别在基础组合上花太多力气抽象，先跑通端到端流程再说。
