Go无内置Observer，需手动实现事件管理；推荐用uintptr+sync.RWMutex管理订阅者，异步通知防阻塞，channel队列需谨慎处理缓冲与关闭，生产环境应自建类型安全、支持context的事件系统。
Go 里没有内置 Observer，得自己搭骨架
Go 语言标准库不提供 Observer 或 EventEmitter 类型，也没有类似 Java 的 java.util.Observable 或 C# 的 event 关键字。这意味着事件注册、通知、解绑全靠手动管理——不是“能不能做”，而是“怎么组织才不容易漏掉 goroutine 泄漏或并发 panic”。核心难点不在逻辑，而在生命周期和线程安全。
用 map[uintptr]func() + sync.RWMutex 管理订阅者最稳妥
别用 map[string]func() 做 key（名字冲突、拼写错误难排查），也别用 func() 本身作 key（函数值不可比较）。推荐用 uintptr 标识订阅者，配合 unsafe.Pointer 获取唯一地址，再加读写锁保护 map 并发访问：
type EventManager struct {
mu sync.RWMutex
listeners map[uintptr]func(interface{})
}
func (e *EventManager) On(fn func(interface{})) uintptr {
ptr := uintptr(unsafe.Pointer(&fn))
e.mu.Lock()
if e.listeners == nil {
e.listeners = make(map[uintptr]func(interface{}))
}
e.listeners[ptr] = fn
e.mu.Unlock()
return ptr
}
func (e *EventManager) Off(ptr uintptr) {
e.mu.Lock()
delete(e.listeners, ptr)
e.mu.Unlock()
}
func (e *EventManager) Emit(data interface{}) {
e.mu.RLock()
defer e.mu.RUnlock()
for _, fn := range e.listeners {
go fn(data) // 异步通知，避免阻塞发布者
}
}
-
Off()必须传入On()返回的uintptr，不能靠函数名或闭包内容匹配 -
Emit()内部用RUnlock()配对，且每个 handler 启 goroutine 执行，防止某个 handler 挂住整个通知链 - 如果需要顺序执行（如日志链、校验链），去掉
go，但必须明确承担阻塞风险
用 channel 实现事件队列时，注意缓冲区与关闭时机
当事件量大、需削峰或保序时，用 channel 更自然，但容易在 close() 和 range 上出错：
type EventQueue struct {
ch chan interface{}
}
func NewEventQueue(buf int) *EventQueue {
return &EventQueue{ch: make(chan interface{}, buf)}
}
func (q *EventQueue) Emit(data interface{}) {
select {
case q.ch <- data:
default:
// 缓冲满，丢弃或打日志，不要阻塞
}
}
func (q *EventQueue) Listen(handler func(interface{})) {
go func() {
for data := range q.ch {
handler(data)
}
}()
}
- 缓冲区大小
buf不是越大越好：过大会吃内存，过小会频繁丢事件；建议按峰值 QPS × 平均处理延迟预估 -
Listen()启动 goroutine 后，EventQueue自身不负责关闭ch；关闭责任应交给上层控制器（比如服务 shutdown 阶段） - 不要在
handler里直接向同一ch再Send，否则可能死锁（除非用不同 channel 或加中间 broker）
第三方库如 github.com/smallstep/go-eventbus 适合快速验证，但别直接进生产
这类轻量库解决了基础注册/通知，但通常缺失：context.Context 透传、事件过滤、监听器优先级、错误重试策略。例如：
立即学习“go语言免费学习笔记（深入）”；
bus := eventbus.New()
bus.Subscribe("user.created", func(e eventbus.Event) {
// e.Data 是 interface{}，类型断言易 panic
if user, ok := e.Data.(User); !ok {
return // 必须检查
}
// ...
})- 所有事件数据都走
interface{}，意味着每次消费都要做类型检查，漏掉就 panic - 订阅字符串
"user.created"是 magic string，重构时无法被 IDE 识别，容易拼错或遗漏更新 - 没提供
SubscribeWithContext()，无法控制单个 listener 的超时或取消
真正需要稳定事件流的场景（比如订单状态机、微服务间异步通知），应该基于 sync.Map + chan + context 自建，把事件类型定义为具体 struct，把订阅动作封装成带校验的函数调用——而不是依赖字符串匹配和运行时断言。
