go中用chan实现事件总线需封装eventbus，用map[string][]chan interface{}+sync.rwmutex管理订阅，避免chan interface{}全局广播，推荐具体struct事件类型和type switch分发，并提供unsubscribe防止泄漏。
Go 里用 chan 做事件总线是最轻量且可控的方式
不用引入第三方库也能跑通核心流程，关键是把事件类型、发布/订阅逻辑和生命周期管理收束清楚。Go 的 chan 天然支持 goroutine 安全的异步通信，但直接裸用 chan 容易掉进阻塞、泄漏、类型不安全的坑。
推荐封装一个 EventBus 结构体，内部用 map[string][]chan interface{} 存订阅者，用 sync.RWMutex 保护注册/注销过程。注意：不要用 chan interface{} 全局广播——类型擦除后无法做编译期校验，运行时 panic 风险高。
- 事件类型建议定义为具体 struct（如
OrderCreatedEvent），而非字符串或空接口 - 订阅时传入带类型的 handler 函数，内部用 type switch 或反射做分发（小项目用前者更清晰）
- 务必提供
Unsubscribe()方法并返回取消函数，否则 goroutine 持有 channel 引用会导致内存泄漏
如何避免 select + default 导致事件丢失
常见错误是用 select { case ch 来防阻塞，这在高并发写入时会静默丢事件。真正健壮的做法是：给每个 subscriber channel 设置缓冲（比如 <code>make(chan Event, 16)），并在 handler goroutine 中循环读取，同时监控 channel 关闭信号。
如果业务能容忍延迟，还可以加一层队列（如 slice + sync.Mutex）做暂存，但要注意锁粒度——别让整个事件分发被单个慢 handler 拖垮。
立即学习“go语言免费学习笔记（深入）”；
- 缓冲大小不是越大越好，16~64 是较稳妥的起点；超过 256 就该考虑是否设计不合理
- handler 内部若调用外部 HTTP/API，必须设超时，否则会卡住整个 channel 接收循环
- 测试时用
time.AfterFunc模拟慢 handler，观察事件堆积和 goroutine 数增长情况
为什么不要在 init() 里注册全局事件监听器
看似方便，实则破坏依赖边界。比如 A 包 init 里订阅了 "user.login"，B 包 init 里也订阅同名事件，但 B 依赖 A —— 此时 A 的 handler 可能早于 B 初始化完成，导致部分事件漏处理。更糟的是，测试时 import 顺序变化会让行为不一致。
正确做法是把订阅逻辑下沉到业务初始化函数中，例如 app.Start() 或 server.Run() 里统一调用 bus.Subscribe("order.created", handleOrderCreated)。
- 所有事件名应集中定义在
event/types.go，避免字符串散落各处 - handler 函数签名统一为
func(Event) error，便于中间件注入（如日志、重试） - 单元测试时可传入 mock channel 或直接调用 handler，无需启动完整 bus
HTTP 请求完成触发事件时，如何保证事务一致性
典型场景：用户下单成功，数据库写入完成，再发 OrderCreatedEvent。如果先发事件后写 DB，失败会导致状态不一致；如果先写 DB 再发事件，发事件失败又会造成下游缺失通知。
最简方案是在事务提交后、HTTP 返回前同步触发事件（适合低频核心事件）；高频或非关键事件可用「本地消息表」模式：写 DB 时连带插入一条 outbox_event 记录，另起 goroutine 轮询该表并投递，失败则重试。
- 同步触发要控制 handler 执行时间，超时直接记录告警，不阻塞响应
- 本地消息表需配合唯一索引防止重复投递，消费端也要做幂等（如用
event_id去重） - 别用 Redis Stream 做事件总线来替代 DB 消息表——它不保证持久化语义，宕机可能丢事件
实际落地时，最难的不是写 bus，而是界定哪些该走事件、哪些该直调。比如「修改用户邮箱后发验证码」是强依赖，适合同步调用；而「更新用户积分」可以异步，但得确保最终一致。这类判断比代码本身更消耗精力。
