如何在Golang语言学习中实现观察者模式处理事件订阅-Golang-PHP中文网

结论：用 func(event interface{}) 类型注册回调最轻量，但必须配 sync.rwmutex 和切片快照，否则并发下会 panic 或漏通知；因读锁期间 observers 可能被修改导致 panic，正确做法是先拷贝快照再遍历。

如何在golang语言学习中实现观察者模式处理事件订阅

直接说结论：用 func(event interface{}) 类型注册回调最轻量，但必须配 sync.RWMutex 和切片快照，否则并发下会 panic 或漏通知。

为什么不能直接遍历 `observers` 切片调用回调

常见错误是写成这样：

func (s *Subject) Notify(event interface{}) {
    s.mu.RLock()
    for _, o := range s.observers {
        o.Update(event) // ❌ 此时若另一个 goroutine 正在调 <code>Unregister</code>，就可能 panic
    }
    s.mu.RUnlock()
}

问题出在：读锁期间，s.observers 仍可能被其他 goroutine 修改（比如移除元素），导致切片底层数组重分配或长度突变。Go 运行时会检测并 panic。

正确做法是先拷贝一份快照：obsCopy := append([]Observer(nil), s.observers...)
拷贝后立即释放读锁，再遍历 obsCopy —— 安全、无阻塞、不干扰其他注册/注销操作
如果观察者数量极少（sync.Map + token 注销机制

`func(event interface{})` 作为观察者比接口更灵活，但要注意类型断言

定义函数类型替代接口，能省掉结构体包装，适合日志、指标等简单逻辑：

type EventHandler func(event interface{})
func (f EventHandler) Update(event interface{}) { f(event) }

sub.Register(EventHandler(func(e interface{}) {
    if data, ok := e.(string); ok {
        fmt.Println("✅", data)
    }
}))

但 interface{} 签名是双刃剑：

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

✅ 编译期不校验事件结构，写错字段名 runtime 才 panic
✅ 同一 Subject 可混发不同事件类型（如 "user.login" 和 OrderPaidEvent{ID: "O123"}）
❌ 生产环境建议为每类事件定义专用 handler，例如 type UserLoginHandler func(*User)，避免类型断言失败

循环中注册闭包，为什么所有 handler 都打印同一个值

典型错误代码：

for _, id := range orderIDs {
    sub.Register(EventHandler(func(e interface{}) {
        fmt.Println("order:", id) // ❌ 全部输出最后一个 id
    }))
}

原因：所有闭包捕获的是同一个变量 id 的地址，循环结束时它已定格为末尾值。

修复方式一：在循环内用新变量赋值：id := id，让每个闭包捕获各自副本
修复方式二：用立即执行函数传参：func(id string) { ... }(id)
⚠️ 注意：若 id 是指针或大结构体，拷贝成本高，应只捕获必要字段（如 id.String()）

异步通知不是加 `go handler(event)` 就完事

盲目起 goroutine 会引发两个问题：

goroutine 泄漏：handler 内部有阻塞调用（如没设 timeout 的 http.Client.Do()），且没人回收
内存失控：突发大量事件，瞬间起几千 goroutine，OOM 风险极高
正确姿势是用带缓冲 channel + 固定 worker pool：events := make(chan Event, 128)，启动 3–5 个 goroutine 消费
每个 handler 必须接收 context.Context 并设超时，例如 ctx, cancel := context.WithTimeout(ctx, 3*time.Second)

真正难的不是怎么发事件，而是 handler 里那行没加 context 的 db.QueryRow() —— 它会让整个通知链卡死，且问题只在压测时暴露。