Go中观察者模式通过Observer/Subject接口实现松耦合事件分发，需用读写锁+快照保障并发安全，推荐泛型约束事件类型并避免阻塞通知、内存泄漏与循环引用。
在 Go 中实现观察者模式，核心是定义“被观察者”（Subject）和“观察者”（Observer）的契约，并通过注册、通知、解绑机制完成松耦合的事件分发。Go 没有内置 interface 继承或泛型约束（旧版），但借助接口（interface）和切片（[]Observer），完全可以简洁、安全地实现该模式——关键是避免内存泄漏和并发竞争。
定义 Observer 和 Subject 接口
先约定行为：观察者需能接收事件；被观察者需支持增删监听器与广播通知。
Observer 接口只需一个方法：
-
Update(event interface{})：接收任意类型事件（生产中建议用具体事件结构体，而非空接口）
Subject 接口包含三个基本能力：
立即学习“go语言免费学习笔记（深入）”；
-
Register(o Observer)：添加观察者 -
Deregister(o Observer)：移除观察者（防止重复通知或 goroutine 泄漏） -
Notify(event interface{})：遍历所有已注册观察者并调用其 Update
实现线程安全的事件总线（推荐做法）
实际项目中，Subject 常被多个 goroutine 并发操作（如异步任务触发事件、HTTP handler 注册监听）。必须加锁保护观察者列表。
示例简明实现：
type EventBroker struct {
mu sync.RWMutex
observers []Observer
}
func (eb *EventBroker) Register(o Observer) {
eb.mu.Lock()
defer eb.mu.Unlock()
eb.observers = append(eb.observers, o)
}
func (eb *EventBroker) Deregister(o Observer) {
eb.mu.Lock()
defer eb.mu.Unlock()
for i, obs := range eb.observers {
if obs == o {
eb.observers = append(eb.observers[:i], eb.observers[i+1:]...)
break
}
}
}
func (eb *EventBroker) Notify(event interface{}) {
eb.mu.RLock()
// 复制一份快照，避免遍历时被修改（尤其 deregister 可能发生）
obsCopy := make([]Observer, len(eb.observers))
copy(obsCopy, eb.observers)
eb.mu.RUnlock()
for _, o := range obsCopy {
o.Update(event)
}}
注意：使用读写锁 + 快照复制，可避免 Notify 过程中因 Deregister 导致的 panic 或漏通知。
定义具体事件与观察者（类型安全增强）
用空接口虽灵活，但易出错。更推荐为不同业务定义事件类型：
type UserCreatedEvent struct {
UserID int64
Username string
Email string
}
type UserObserver struct{}
func (uo *UserObserver) Update(event interface{}) {
if e, ok := event.(UserCreatedEvent); ok {
log.Printf("User created: %s (%d)", e.Username, e.UserID)
}
}
也可用泛型（Go 1.18+）进一步约束：
type TypedObserver[T any] interface {
Update(event T)
}
type TypedBroker[T any] struct {
mu sync.RWMutex
observers []TypedObserver[T]
}
func (tb TypedBroker[T]) Notify(event T) { / ... */ }
这样编译期就能检查事件类型匹配，减少运行时断言错误。
避免常见陷阱
- 不要在 Update 中阻塞或执行耗时操作：否则会拖慢整个 Notify 流程。应启动 goroutine 或投递到 worker 队列
- 观察者注册后未解绑 → 内存泄漏：尤其在 HTTP handler 或长生命周期对象中注册了短生命周期 observer（如临时闭包）。务必配对 Deregister 或用 context 控制生命周期
- 循环引用风险：Subject 持有 Observer 引用，Observer 又持有 Subject 引用（比如闭包捕获）→ GC 无法回收。建议 Observer 不反向持有 Subject
- 不保证通知顺序：Go 切片遍历顺序确定，但若用 map 存储 observers（为 O(1) 删除），则顺序不可靠。如需严格顺序，坚持用 slice + 线性查找
基本上就这些。观察者模式在 Go 里不复杂但容易忽略并发和生命周期细节——接口清晰、锁粒度合理、事件类型明确，就能稳稳支撑模块解耦与事件驱动架构。
