Golang观察者模式实现与事件通知示例

本文深入解析了Go语言中观察者模式的手动实现要点，指出由于Go缺乏内置Observer接口或事件关键字，开发者必须自行构建安全可靠的事件通知机制：通过带唯一ID的映射表管理订阅者、利用sync.RWMutex保障并发安全、避免使用无法比较和删除的函数值作为map键，并重点强调异步通知时需借助goroutine配合超时或非阻塞channel发送，以防止因慢消费者导致的发布阻塞和资源泄漏——这是一份直击Go生态实践痛点、兼顾原理与工程落地的硬核指南。

Go 里没有内置的 Observer 接口，得自己搭骨架

Go 语言不提供类似 Java 的 java.util.Observer 或 C# 的 event 关键字，所有观察者逻辑必须手动组合。核心就三样：map 存订阅者、sync.RWMutex 保并发安全、用函数类型当回调。别试图找“标准库实现”，它不存在。

常见错误是直接用 map[interface{}]func() 存 handler，结果发现无法比较函数值、不能删除特定订阅、也不支持泛型事件类型。正确做法是给每个订阅分配唯一 id（比如 int64 或 uuid.UUID），再用 map[int64]func(interface{}) 管理。

用 channel 实现异步通知时要注意阻塞和泄漏

有人喜欢让每个 observer 拿一个 chan interface{}，发布者往所有 channel 发送事件。这在高并发或慢消费者场景下极易卡死：一旦某个 channel 没人收，publish 就会永久阻塞。

更稳妥的做法是把通知逻辑放到 goroutine 里，并加超时或非阻塞发送：

go func(handler func(interface{})) {
    select {
    case <p>还要记得在取消订阅时关闭对应 channel（如果用了 channel），否则可能引发 goroutine 泄漏。</p><h3>泛型版 EventBus 需要按事件类型分发，不能只靠 interface{}</h3><p>用 <code>interface{}</code> 做事件载体看似灵活，实际会导致运行时类型断言失败、无法静态检查、IDE 失去提示。Go 1.18+ 推荐用泛型约束事件类型：</p><pre class="brush:php;toolbar:false">type Event interface{ ~string | ~int | MyCustomEvent }
<p>type EventBus[T Event] struct {
handlers map[int64]func(T)
mu       sync.RWMutex
nextID   int64
}</p><p>func (e *EventBus[T]) Subscribe(handler func(T)) int64 {
e.mu.Lock()
defer e.mu.Unlock()
id := atomic.AddInt64(&e.nextID, 1)
e.handlers[id] = handler
return id
}</p><p>func (e *EventBus[T]) Publish(event T) {
e.mu.RLock()
defer e.mu.RUnlock()
for _, h := range e.handlers {
h(event)
}
}</p>

这样调用时就能明确约束事件类型：bus := &EventBus[UserCreated]{} ，编译器会帮你拦住传错类型的 bug。

取消订阅必须支持精确移除，不能只靠 defer 或全局清理

很多示例用 defer unsubscribe()，但真实服务中 observer 生命周期往往跨 HTTP 请求、gRPC 流或长连接，没法靠 defer 自动触发。必须提供显式 Unsubscribe(id int64) 方法，并确保线程安全。

容易忽略的点：

• 多次调用 Unsubscribe 同一个 id 应静默成功（幂等）
• 遍历时不能直接从 map 删除（Go runtime panic），要用两阶段：先收集 key，再循环删除
• 若用 sync.Map 替代 map + mutex，注意 LoadAndDelete 是原子的，但遍历仍需额外同步

真正难的不是写通逻辑，而是让取消行为在分布式、重连、超时、panic 恢复等各种边界下依然可靠 —— 这需要结合 context、心跳检测和持久化订阅状态，不是单个 EventBus 能解决的。

以上就是《Golang观察者模式实现与事件通知示例》的详细内容，更多关于的资料请关注golang学习网公众号！