Golang观察者模式与Channel通知实现

本文深入探讨了在Go语言中如何更地道、高效地实现观察者模式——摒弃传统Java风格的接口+列表+互斥锁方案，转而采用channel作为核心通信机制：每个观察者独占一个`chan interface{}`，被观察者仅负责向所有通道广播事件，天然实现异步、解耦与无竞态；观察者则自行启动goroutine监听并处理消息，彻底避免通知过程阻塞发布方或因单个慢观察者拖垮整体性能，真正发挥Go并发模型的优势。

用 channel 实现观察者注册和通知，别用 map + mutex

Go 里最自然的观察者不是靠接口+列表+锁模拟 Java 风格，而是用 chan 做事件管道。核心思路是：每个观察者独占一个 chan interface{}，被观察者往所有通道里发消息——这样天然异步、解耦、无竞态。

常见错误是把所有观察者塞进一个 map[string]func()，再配个 sync.RWMutex，结果通知时阻塞主线程，某个观察者卡住就拖垮全部。

• 观察者启动 goroutine 监听自己的 notifyCh，收到消息后自行处理，不反向阻塞发布方
• 被观察者只负责“发”，不关心谁收、怎么收、收没收到
• 注册时直接传入 chan，避免暴露接收端，防止误写

如何安全关闭观察者 channel，避免 panic: send on closed channel

观察者退出时必须关自己的 notifyCh，但被观察者可能还在往里面发。直接关会触发 panic: send on closed channel。

正确做法是让被观察者维护一个 sync.Map 记录每个 chan 是否已注销，发消息前先查；或者更轻量：用 select + default 非阻塞发送。

• 推荐非阻塞发送：

  select {
  case ch 

• 不要在观察者 goroutine 里关 ch 后立刻从被观察者列表中删——得先确保被观察者不再往它发，否则 race
• 如果用缓冲 channel（如 make(chan T, 1)），default 分支能防住瞬时积压，但不能替代生命周期管理

事件类型怎么设计？interface{} 不够用，但泛型又太重

用 chan interface{} 看似灵活，实际容易在接收端类型断言失败，比如 v, ok := ，一旦发错类型就 panic。

折中方案是定义一个最小公共事件接口，比如 type Event interface{ Type() string; Timestamp() time.Time }，具体事件嵌入它；或者直接上 Go 1.18+ 泛型，封装成 Observer[T any]。

• 简单场景：用 struct{ Type string; Payload any }，接收方 switch event.Type 再 cast event.Payload
• 高频事件（如监控指标推送）：泛型更安全，type Broadcaster[T any] struct{ chs []chan，编译期校验
• 避免在 channel 里传大结构体，尤其是含指针或 map 的——要传指针或用 sync.Pool 复用

为什么不用 context.Context 控制观察者生命周期？

context.Context 适合控制“请求级”超时或取消，不适合管理长期运行的观察者。一来 ctx.Done() 只能通知一次，二来观察者可能需在取消后做清理（如关数据库连接），而 context 不提供钩子。

真正该用的是显式注销函数 + done channel 组合。

• 注册返回 func() 注销函数，内部 close 观察者 channel 并从被观察者列表中移除
• 观察者 goroutine 应监听自己的 doneCh（非 ctx.Done()），收到后清理资源再退出
• 如果非要集成 context，只在注销函数里 select 等待 ctx.Done() 做超时保护，别让它主导流程

channel 实现观察者最易错的点不在“怎么发”，而在“谁关 channel、何时关、关完是否还被引用”。多一个 goroutine 就多一个生命周期，别指望 runtime 帮你兜底。

本篇关于《Golang观察者模式与Channel通知实现》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！