Go无内置事件总线，推荐用channel+select或轻量库如asaskevich/EventBus；需注意缓冲区、不可变事件、监听器panic防护及跨服务场景须用消息队列。
Go 里没有内置的事件总线，得自己搭或选轻量库
Go 标准库不提供 EventBus 或类似 dispatch / on 的抽象，这不是遗漏，是设计取舍：它倾向显式通信（channel、interface）而非隐式事件传递。硬套其他语言的事件驱动模型，容易写出难以追踪的回调链。
实际项目中，真需要事件驱动，常见做法就两种：用 channel + select 做简易发布/订阅，或者引入像 github.com/asaskevich/EventBus 这类无依赖、仅几百行的库。别碰带反射、自动注册、跨进程的“全功能”事件框架——在 Go 里它们多半是过度设计，还藏 goroutine 泄漏风险。
- 用
channel时，注意缓冲区大小：0 容量易阻塞发布者；过大则内存堆积 - 用第三方库时，确认它是否支持
WithContext，否则监听器 panic 会 kill 整个 bus - 所有事件结构体必须是值类型或明确生命周期管理，避免闭包捕获局部变量导致内存逃逸
用 channel 实现事件广播时，别直接传指针或 map
典型错误是定义 type Event struct{ Data *map[string]interface{} }，然后往 channel 里发。这会导致多个监听器看到同一份可变数据，A 修改了 Data，B 下一秒读到的就是脏值——Go 的 channel 传递的是副本，但指针副本指向的还是同一块内存。
正确做法是让事件 payload 不可变，或每次广播前深拷贝。简单场景下，直接用结构体字段存原始值更安全：
立即学习“go语言免费学习笔记（深入）”；
type UserCreatedEvent struct {
UserID int64
Email string
CreatedAt time.Time
}
- 避免在事件结构体里放
sync.Mutex、http.Client等非序列化类型 - 如果必须传复杂对象，用
json.RawMessage或[]byte显式序列化，接收方按需解析 - 不要用
interface{}做事件类型，类型断言失败时 panic 不提示来源，调试极难
监听器 panic 会导致整个事件循环崩溃
用 for range chan 做事件分发时，如果某个监听器函数 panic，而你没 recover，整个 for 循环就退出了——后续事件全丢，且无日志。这不是“异常未捕获”的常规问题，而是事件驱动架构里最隐蔽的单点故障。
必须在每个监听器调用处加保护：
go func(handler EventHandler) {
defer func() {
if r := recover(); r != nil {
log.Printf("event handler panic: %v", r)
}
}()
handler(event)
}(h)
- 别把 recover 放在事件总线外层——那只能 catch 发布逻辑的 panic，不是监听器的
- 监听器内禁止 long-running 操作（如 HTTP 调用），超时控制必须由监听器自己做，总线不负责
- 测试时故意让一个监听器 panic，验证其他监听器是否照常执行
跨服务事件该用消息队列，别用本地 channel 或 EventBus
当你说“用户注册后发邮件、写日志、通知推送”，如果这三个动作在不同进程或容器里，channel 和 EventBus 就完全失效。它们只在单进程内有效，且无法保证投递成功、重试、顺序、幂等。
这时候必须切到真正的消息中间件：Kafka、NATS、RabbitMQ 或 Cloud Pub/Sub。Go 客户端（如 sarama、nats.go）只负责收发，事件语义（比如“最终一致性”“至少一次”）得靠业务代码补全。
- 本地事件总线和消息队列不能混用一套接口抽象——它们的错误模型、延迟特征、监控方式完全不同
- 别在 Kafka consumer 里再套一层
EventBus：增加无谓跳转，掩盖真实瓶颈 - 消息体尽量保持小（
