用 sync.map + 函数类型实现轻量事件总线：type eventhandler func(interface{})，每个 topic 对应 []eventhandler，注册时 load-append-store，notify 时 goroutine 异步调用并 recover，注销靠显式 id 而非接口值比较。
用 sync.Map + 函数类型实现轻量事件总线，别写接口套娃
Go 里硬套 Java 风格的 Observer 接口+结构体继承，只会让代码变重、解耦失败。真实项目中，90% 的事件通知场景只需要“某事发生后调用几个函数”，不需要生命周期管理或泛型约束。
直接用函数当观察者最自然：type EventHandler func(interface{})，注册时传个闭包就行，没抽象成本，也无类型擦除风险。
- 避免定义
Update(event interface{})接口再包装一层——多一次接口值拷贝，还容易因方法值不等导致Detach失效 -
sync.Map比map + sync.RWMutex更适合高频读写场景（比如配置热更新监听），但注意它不支持遍历，得为每个 topic 单独配一个[]EventHandler - 注册时别用
append原地修改切片——并发下会 panic；应先Load出原切片，append后Store回去
Notify 必须异步，且每个 handler 要单独 recover
同步调用 obs.Update(event) 是最大陷阱：一个 handler 执行慢、卡死或 panic，整个通知就阻塞或崩掉，其余观察者收不到事件。
正确做法是为每个 handler 启一个 goroutine，并在内部 recover：
立即学习“go语言免费学习笔记（深入）”；
go func(h EventHandler) {
defer func() {
if r := recover(); r != nil {
log.Printf("handler panic: %v", r)
}
}()
h(event)
}(handler)- 不推荐全局 goroutine 池——小项目没必要，反而引入调度复杂度
- 高频事件（如每秒千级）慎用无缓冲 channel 中转，容易压垮；带缓冲 channel（如
make(chan Event, 1024)）更稳 - 如果某个 handler 需要上下文（如超时控制），别往
event interface{}里塞context.Context——改用独立参数或封装成结构体字段
动态注销必须带唯一 ID，别依赖接口值相等
Go 没有对象身份语义，o1 == o2 对接口值比较不可靠——尤其是方法值、闭包，哪怕逻辑相同，地址也不同。直接传 Observer 接口去 Unregister，大概率删不掉。
- 注册时显式传
id string，用map[string]EventHandler存储，注销只删 key - HTTP handler 或临时 goroutine 类观察者，建议绑定
context.Context：在OnEvent里检查ctx.Err() != nil，触发后主动调用Detach(id) - 别用
uintptr(unsafe.Pointer(...))做 ID——反射取地址不稳定，GC 可能移动对象，生产环境已出过 case
什么时候该放弃自研，改用 chan 直连
不是所有场景都需要“可订阅/可注销”的总线。如果你只有 1–3 个固定消费者，且事件种类单一（比如仅日志、指标、审计），chan 是更 Go 的选择。
- 用
select { case logCh 控制背压，比总线里的 map 查找+切片遍历更快 - channel 天然支持 select 超时、取消、多路复用，和 context 集成更干净
- 一旦需要按 topic 分类、通配符匹配（如
user.*）、或运行时插拔 handler，就该切回sync.Map版本，别硬撑
真正难的不是实现 Notify，而是想清楚：这个事件到底要不要被多个模块监听？监听者生命周期谁管？丢事件能不能接受？把这三个问题答清了，选 chan 还是 EventBus 就不会错。
