Go 无内置 EventBus，需手动实现；应采用事件名+结构体参数+同步通知的轻量方案，用 sync.RWMutex 保护 map，定义具体事件结构体保障类型安全，返回 Subscription 句柄确保可靠注销。
Go 里没有内置 EventBus，得自己搭骨架
Go 语言标准库不提供 EventBus 或 Observer 接口，这不是遗漏，是设计取舍：它倾向显式依赖、小接口、组合优先。想用观察者模式，就得自己定义事件分发逻辑，而不是找一个“开箱即用”的黑盒。
常见错误是直接套 Java/C# 的思路，搞出一堆泛型接口、反射注册、异步队列——结果调试困难、竞态频发、GC 压力大。实际项目里，90% 的场景只需要：事件名 + 参数结构体 + 同步通知。
- 用
map[string][]func(interface{})存事件处理器最轻量，适合配置变更、状态流转等低频通知 - 避免在 handler 里做耗时操作（比如 HTTP 调用、DB 写入），否则会阻塞后续监听者
- 如果真需要异步，显式起 goroutine，别藏在
Publish里——调用方得清楚控制权在哪
用 sync.RWMutex 保护 map，别信“读多写少就不用锁”
很多人试过不用锁，靠 channel 或原子操作兜底，但 map 本身不是并发安全的，哪怕只读也 panic。Go 运行时对 map 并发读写检测非常严格，fatal error: concurrent map read and map write 是高频报错。
正确做法是用 sync.RWMutex 包一层，读操作用 RLock，注册/注销用 Lock：
立即学习“go语言免费学习笔记（深入）”；
type EventBus struct {
mu sync.RWMutex
handlers map[string][]func(interface{})
}
<p>func (e *EventBus) Subscribe(event string, f func(interface{})) {
e.mu.Lock()
defer e.mu.Unlock()
e.handlers[event] = append(e.handlers[event], f)
}
- 不要把
handlers暴露出去，否则外部直接改 map 会绕过锁 - 注册和注销必须成对加锁，不能一个加锁一个不加
- 如果事件类型固定且数量少，可考虑用 struct 字段替代 map，彻底避开并发问题
事件参数用具体结构体，别传 interface{} + 类型断言
传 interface{} 看似灵活，实则埋雷：调用方和监听者之间零契约，IDE 不提示，编译不检查，运行时报 panic: interface conversion: interface {} is xxx, not yyy。
正确姿势是为每个事件定义专属结构体：
type UserCreatedEvent struct {
UserID int64
Email string
CreatedAt time.Time
}
<p>bus.Publish("user.created", UserCreatedEvent{UserID: 123, Email: "a@b.c"})
- 监听函数签名变成
func(UserCreatedEvent)，类型安全，可直接用字段 - 如果多个事件共用字段，提取为嵌入结构体，别为了“复用”硬塞进一个万能
map[string]interface{} - 别在事件结构体里放指针或切片（除非你明确管理生命周期），避免监听者修改影响其他 handler
取消订阅容易漏掉，用 defer + 句柄比字符串匹配靠谱
用事件名字符串注册后，注销时再传一遍字符串，极易拼错或大小写不一致，导致内存泄漏（handler 一直留在 map 里）。
更可靠的方式是返回一个取消函数句柄：
type Subscription struct {
bus *EventBus
event string
fn func(interface{})
}
<p>func (s *Subscription) Unsubscribe() {
s.bus.mu.Lock()
defer s.bus.mu.Unlock()
// 从 handlers[event] 中删掉 s.fn（需遍历+剪切）
}
- 注册时返回
*Subscription，业务代码用defer sub.Unsubscribe()确保清理 - 别依赖
reflect.ValueOf(fn).Pointer()做去重——闭包函数指针可能重复，不可靠 - 如果监听者生命周期短（比如 HTTP handler 里临时注册），务必记得注销，否则 event bus 会悄悄持有引用，阻止 GC
真正麻烦的不是写一个能跑的 EventBus，而是让所有协程都清楚：谁注册、谁注销、事件参数有没有被意外修改、handler panic 会不会让整个发布流程中断。这些细节不显眼，但线上出问题时，90% 都卡在这儿。
