Golang观察者模式实现与应用解析
Go中不用interface{}做观察者事件参数,因其导致运行时panic频发、类型断言失败难定位,根本原因是丢失编译期类型约束;应为每类事件定义具体结构体并统一实现Event接口。
Go中不用interface{}做观察者事件参数,因其导致运行时panic频发、类型断言失败难定位,根本原因是丢失编译期类型约束;应为每类事件定义具体结构体并统一实现Event接口。

为什么 Go 里不用 interface{} 做观察者事件参数
Go 没有泛型前,不少人用 interface{} 当事件数据载体,结果运行时 panic 频发,类型断言失败还难定位。根本问题在于丢失了编译期类型约束,一旦通知逻辑稍复杂(比如多个事件类型混发),消费者端很容易漏处理或误转型。
更稳妥的做法是为每类事件定义具体结构体,再通过接口统一通知入口。例如:
type Event interface {
EventType() string
}
type UserCreatedEvent struct {
UserID int64
Username string
}
func (e UserCreatedEvent) EventType() string { return "user.created" }
- 所有事件实现
Event接口,便于统一注册和分发 - 避免在
Notify()方法里塞interface{}参数,改用具体类型接收 - 如果用 Go 1.18+,可配合泛型写一个类型安全的
Subject[T Event],但多数业务场景中明确的事件结构已足够
如何避免观察者注册/注销时的竞态问题
多个 goroutine 同时调用 Register() 或 Unregister() 会导致切片操作 panic,或者漏掉某个观察者——这是最常被忽略的并发陷阱。
必须加锁,但别直接锁整个通知过程(否则 Notify 变成串行,失去并发意义):
type Subject struct {
mu sync.RWMutex
observers []Observer
}
func (s *Subject) Register(o Observer) {
s.mu.Lock()
defer s.mu.Unlock()
s.observers = append(s.observers, o)
}
func (s *Subject) Notify(event Event) {
s.mu.RLock() // 只读锁,允许并发 Notify
defer s.mu.RUnlock()
for _, o := range s.observers {
o.OnEvent(event)
}
}
- 注册/注销走
Lock(),通知走RLock(),性能和安全兼顾 - 切忌在
Notify()中遍历时修改s.observers(比如一边通知一边注销),应先拷贝一份快照:obs := append([]Observer(nil), s.observers...) - 如果观察者可能长时间阻塞(如发 HTTP 请求),建议在 Notify 内启 goroutine 异步调用,但需自行管理生命周期,防止 goroutine 泄漏
什么时候该用 channel 替代切片存观察者
当观察者数量少、事件频率低、且需要强顺序保证时,切片 + 锁完全够用;但若出现以下任一情况,channel 更合适:
- 观察者处理速度差异大,部分慢观察者拖垮整体吞吐
- 需要支持背压(如限流、超时、丢弃旧事件)
- 事件源和观察者天然解耦(比如跨 goroutine、跨 package)
典型 channel 实现模式是“扇出”:
type Subject struct {
eventCh chan Event
}
func (s *Subject) Notify(event Event) {
select {
case s.eventCh <- event:
default:
// 可选:丢弃、打日志、触发告警
}
}
// 每个观察者单独起 goroutine 消费
func (s *Subject) AddObserver(handler func(Event)) {
go func() {
for event := range s.eventCh {
handler(event)
}
}()
}
注意:channel 方案要额外处理关闭、泄漏、缓冲区大小等细节,简单业务不推荐过早引入。
为什么不要在 OnEvent 里做耗时同步操作
观察者接口的 OnEvent() 方法默认是同步调用的。如果某个实现里写了数据库写入、HTTP 调用或复杂计算,会直接卡住整个通知链路——其他观察者得干等,甚至触发上层超时。
正确做法是把耗时逻辑移出 OnEvent(),只做轻量分发:
- 发消息到 worker queue(如 Redis Stream、NATS)
- 投递到本地 channel 由后台 goroutine 消费
- 调用异步 SDK(如
logrus.WithField(...).InfoAsync()类似语义)
尤其要注意日志、监控类观察者——它们看似无害,但高并发下 I/O 累积延迟会非常明显。上线前务必压测真实路径下的 Notify() 耗时。


































