Go中无内置EventBus是设计取舍，推荐用map+sync.RWMutex自实现或asaskevich/eventbus库；须传单一结构体参数、严防并发陷阱、避免channel中转高频事件。
Go 里没有内置 EventBus，得自己搭或选轻量库
标准库不提供 EventBus 或 Observer 接口，这不是遗漏，是设计取舍：Go 倾向显式依赖、小接口、组合优先。硬套 Java/C# 的泛型+反射方案，结果往往是调试困难、竞态频发、GC 压力大。
真实项目中，90% 的进程内事件通知场景只需要：事件名 + 具体结构体参数 + 同步或可控异步通知。两种主流路径：
- 自己实现：用
map[string][]func(interface{})+sync.RWMutex是最稳起点，适合配置变更、状态流转等低频通知 - 用第三方库：如
github.com/asaskevich/eventbus，它开箱即用但默认同步、不带类型安全、Publish支持多参数易出错
用 asaskevich/eventbus 时别传多个参数
这个库的 Publish 签名是 func(topic string, args ...interface{})，看着灵活，实则埋雷。比如：
bus.Publish("user.created", 123, "a@b.c", time.Now())订阅方必须按顺序、按类型取值，一旦错位或漏判，运行时 panic：
立即学习“go语言免费学习笔记（深入）”；
func handler(a, b, c interface{}) { id := a.(int) // panic if a is not int }正确做法是只传一个参数，且是具体结构体：
- 定义
UserCreatedEvent结构体，带Type和Version字段（用于后续兼容） bus.Publish("user.created", UserCreatedEvent{UserID: 123, Email: "a@b.c"})- 订阅函数签名统一为
func(UserCreatedEvent)，靠 IDE 提示和编译检查兜底
自己实现 EventBus 必须处理的三个并发陷阱
哪怕只是用 map + sync.RWMutex，以下三点错一个就崩：
-
handlers字段绝不能导出，否则外部绕过锁直接改map，必报fatal error: concurrent map read and map write - 注册和注销都得用
mu.Lock()，不能一个加锁一个不加；遍历 handler 切片前，必须先copy出副本再遍历，否则可能 panic 或漏调 - 每个 handler 内部要包
recover()，否则一个 panic 会中断整个通知流，其余监听者收不到事件
高频事件（如每秒千级）慎用无缓冲 channel 中转
有人喜欢在 EventBus 里塞 chan 做中转，比如 map[string]chan Event。这在低频场景可行，但一到高频就容易压垮：
- 无缓冲
chan会导致 sender 阻塞，拖慢发布方 - 带缓冲的也得谨慎：容量设太小（如
make(chan Event, 1)）照样卡死；设太大（如10240）吃内存且掩盖设计问题 - 真正健壮的做法是：handler 本身起 goroutine 异步执行，并控制超时与错误日志，而不是靠 channel 缓冲扛流量
事件总线不是消息队列，它的核心职责是解耦和分发，不是削峰填谷。峰值压力该由上层限流或降级承担，不该指望 EventBus 自己扛住。
