Go原生无EventBus是因goroutine+channel已满足多数场景，自行实现易致锁竞争、内存泄漏；应聚焦可控的发布-订阅语义：用具体结构体作事件类型、支持取消订阅、非阻塞发布、channel+map实现轻量分发器。
为什么 Go 原生没有 EventBus，但你仍不该自己写一个
Go 语言标准库不提供通用事件总线（EventBus），不是遗漏，而是设计取舍：goroutine + channel 已覆盖大多数事件分发场景，强行抽象易引入锁竞争、内存泄漏或订阅生命周期失控。直接上第三方库（如 github.com/asaskevich/EventBus）看似省事，但多数不处理 goroutine 泄漏、订阅者 panic 传播、或异步/同步混用问题。
真正需要的不是“总线”，而是「可控的发布-订阅语义」：
- 事件类型应为具体结构体，而非
interface{}—— 避免运行时类型断言失败 - 订阅必须支持取消（
unsubscribe或context.CancelFunc），否则热更新或长连接服务会累积 goroutine - 发布端不应阻塞；若需等待所有监听器完成，应显式用
sync.WaitGroup或errgroup.Group
用 channel + map 实现轻量级事件分发器
适合中低频事件（如配置变更、健康检查触发），不追求高吞吐，但要求逻辑清晰、无依赖、可测试。
核心结构体只需三部分：events（事件类型到 chan interface{} 的映射）、mu（读写锁）、subs（用于跟踪订阅者以支持取消）：
立即学习“go语言免费学习笔记（深入）”；
type EventDispatcher struct {
mu sync.RWMutex
events map[reflect.Type]chan interface{}
subs map[reflect.Type][]func(interface{})
}
关键点：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 不要用
map[string]chan做事件类型索引 —— 字符串拼错无编译检查，且无法区分同名不同包类型 - 每个事件类型对应独立 channel，避免不同类型事件互相阻塞
- 监听器注册时返回
func()取消函数，内部从subs中移除该回调，防止重复调用 - 发布时用
select { case ch 防止监听器慢导致发布阻塞（即“背压丢弃”策略）
用 errgroup + context 处理需要结果反馈的事件
当事件监听器需返回错误（如校验失败需中断后续流程），或需等待全部完成再继续（如初始化阶段加载多个插件），channel 模型就不够用了。
此时改用 errgroup.Group + context.Context 更自然：
func (d *EventDispatcher) PublishWithResult(ctx context.Context, event interface{}) error {
etype := reflect.TypeOf(event)
d.mu.RLock()
handlers, ok := d.handlers[etype]
d.mu.RUnlock()
if !ok {
return nil // 无人监听，视为成功
}
<pre class="brush:php;toolbar:false;">g, gctx := errgroup.WithContext(ctx)
for _, h := range handlers {
h := h // 闭包捕获
g.Go(func() error {
select {
case <-gctx.Done():
return gctx.Err()
default:
return h(gctx, event)
}
})
}
return g.Wait()}
注意：
- 监听器函数签名应为
func(context.Context, interface{}) error，便于传递超时与取消信号 - 不能在监听器内启动长期 goroutine 并忽略
ctx—— 否则g.Wait()永不返回 -
errgroup默认并发执行；若需顺序执行，改用循环调用并检查err
什么时候该换消息队列，而不是硬撑
当出现以下任一情况，说明已超出进程内事件驱动的合理边界：
- 事件需要跨进程/跨机器投递（如微服务间通知）→ 直接上
RabbitMQ或Kafka - 事件积压后需持久化、重试、死信处理 → 自研 channel 队列无法替代
NATS JetStream或Redis Streams - 监听器执行时间波动大（毫秒级到分钟级），且不允许丢失 → 进程内 channel 容量有限，OOM 风险高
- 需审计日志、事件溯源、或按时间范围回放 → 必须落地存储，而非内存 channel
Go 的优势在于快速桥接：用 github.com/segmentio/kafka-go 封装一层 Publish() 接口，对外保持事件语义不变，底层却已是分布式可靠传输 —— 这比把 channel 做成“带持久化的伪消息队列”要稳健得多。
