Go 语言实现简单观察者模式教程

本文深入剖析了在 Go 语言中实现观察者模式的常见误区与最佳实践，指出盲目套用 Java/C# 的接口式设计会导致事件签名僵化、类型耦合严重及并发遍历时 panic 等问题；转而推荐以函数值为核心、配合 sync.RWMutex 与快照拷贝机制构建轻量安全的 EventBroker，既规避了 slice 并发修改风险，又通过 Once 订阅和可撤销回调支持一次性监听，同时理性指出——当事件简单、消费者极少且需强顺序时，原生 channel 往往比自建 Broker 更简洁高效，真正体现了 Go “少即是多”与面向工程落地的设计哲学。

为什么 Go 里不用接口定义 Observer 和 Subject 就容易出错

Go 没有内置的继承或抽象类机制，直接照搬 Java/C# 的观察者模式写法（比如定义 Observer 接口带 Update() 方法）会导致两个实际问题：一是调用方必须实现整个接口，哪怕只关心一个事件；二是无法安全地在遍历时增删监听器——map 或 slice 并发读写会 panic，而加锁又容易让通知逻辑阻塞发布者。

更务实的做法是用函数值作为观察者，把“注册”和“通知”行为收束到一个结构体中，由它统一管理生命周期和并发安全：

type EventBroker struct {
    mu       sync.RWMutex
    handlers map[string][]func(interface{})
}
func (e *EventBroker) Subscribe(event string, f func(interface{})) {
e.mu.Lock()
defer e.mu.Unlock()
if e.handlers == nil {
e.handlers = make(map[string][]func(interface{}))
}
e.handlers[event] = append(e.handlers[event], f)
}

如何避免 Notify 时 panic: concurrent map read and map write

最常踩的坑是在 Notify 中一边遍历 handlers[event]，一边其他 goroutine 调用 Subscribe 或 Unsubscribe 修改底层 slice。Go 的 slice 底层是引用类型，即使加了锁，如果只对 map 加锁而没保护 slice 内容，仍可能因底层数组扩容导致数据竞争。

安全做法是：在读取 handler 列表前，先拷贝一份只读快照：

func (e *EventBroker) Notify(event string, data interface{}) {
    e.mu.RLock()
    listeners := make([]func(interface{}), len(e.handlers[event]))
    copy(listeners, e.handlers[event])
    e.mu.RUnlock()
for _, f := range listeners {
    f(data) // 注意：这里不加锁，允许 handler 自行决定是否并发安全
}
}

• 用 RWMutex 提升读多写少场景的吞吐
• copy 出新 slice 后再释放锁，确保遍历过程完全无锁
• 不强制要求 handler 是 goroutine 安全的——这是使用者的责任，和发布者解耦

怎么支持一次性监听和自动反注册

有些事件只需响应一次（如初始化完成、资源加载成功），手动调用 Unsubscribe 容易遗漏。可以在订阅时返回一个取消函数，内部用闭包捕获 handler 地址并从 map 中清理：

func (e *EventBroker) Once(event string, f func(interface{})) func() {
    e.mu.Lock()
    defer e.mu.Unlock()
    if e.handlers == nil {
        e.handlers = make(map[string][]func(interface{}))
    }
    e.handlers[event] = append(e.handlers[event], f)
return func() {
    e.mu.Lock()
    defer e.mu.Unlock()
    if hlist, ok := e.handlers[event]; ok {
        for i, h := range hlist {
            if h == f {
                e.handlers[event] = append(hlist[:i], hlist[i+1:]...)
                break
            }
        }
    }
}
}

注意：这个方案依赖函数值相等性判断（Go 中函数值可比较），但仅限于普通函数字面量或相同变量赋值；若传入闭包且捕获了不同变量，比较会失效——这种场景应改用唯一 ID 管理。

什么时候该放弃自建 Broker 而用 channel + select

如果事件种类极少（比如只有 "done" 和 "error"）、消费者固定为 1–2 个、且需要强顺序和背压控制，直接用 chan interface{} 更轻量。例如：

type Task struct {
    doneCh chan struct{}
    errCh  chan error
}
func (t *Task) OnDone(f func()) {
go func() {
<-t.doneCh
f()
}()
}

但 channel 方案难以支持一对多、按事件名分发、动态增删——这些正是 EventBroker 存在的理由。选型关键不在“模式是否标准”，而在“你的事件流量是否真需要解耦与弹性”。

真正容易被忽略的是 handler 执行失败的处理：默认静默吞掉 panic，但生产环境建议用 recover 日志记录，并考虑是否要中断后续 handler 执行（这需要在 Notify 中加错误返回路径）。

到这里，我们也就讲完了《Go 语言实现简单观察者模式教程》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！