Go中轻量观察者语义首选chan，因其异步解耦、无样板代码；需动态管理时用sync.Map+atomic；应克制抽象，优先函数参数直连。
Go 语言没有内置的 Observer 接口或事件总线，直接套用传统 OOP 的观察者模式容易写出难以维护的强耦合代码。关键不是“怎么实现”，而是“在 Go 里该不该、以及如何轻量地达成观察者语义”。
为什么 chan 比接口回调更适合 Go 中的简单观察场景
多数业务中需要的只是“某事发生后通知其他模块”，并不需要动态增删观察者或复杂生命周期管理。此时用 chan 配合 goroutine 是更符合 Go 习惯的做法：
-
chan天然支持异步解耦，发送方不阻塞（用select+default或带缓冲通道） - 避免为每个观察者定义独立接口和注册方法，减少样板代码
- 错误传播清晰：若接收端 panic 或关闭 channel，发送端可通过
select+ok判断 - 不适合高频、多观察者、需精确控制通知顺序的场景（这时应考虑第三方库如
github.com/smallstep/go-eventbus）
用 sync.Map 实现可动态注册/注销的观察者管理
当确实需要运行时增删观察者（比如插件系统、配置热更新监听），可以用 sync.Map 存储回调函数，配合 atomic 控制状态：
type EventBroker struct {
handlers sync.Map // map[string][]func(interface{})
mu sync.RWMutex
}
func (e *EventBroker) Subscribe(topic string, f func(interface{})) {
e.mu.Lock()
defer e.mu.Unlock()
if list, ok := e.handlers.Load(topic); ok {
e.handlers.Store(topic, append(list.([]func(interface{})), f))
} else {
e.handlers.Store(topic, []func(interface{}){f})
}
}
func (e *EventBroker) Notify(topic string, data interface{}) {
if list, ok := e.handlers.Load(topic); ok {
for _, f := range list.([]func(interface{})) {
go f(data) // 异步调用，避免阻塞通知流程
}
}
}
注意点：
立即学习“go语言免费学习笔记（深入）”；
《PHP设计模式指南》中文版
下载
《PHP设计模式》首先介绍了设计模式，讲述了设计模式的使用及重要性，并且详细说明了应用设计模式的场合。接下来，本书通过代码示例介绍了许多设计模式。最后，本书通过全面深入的案例分析说明了如何使用设计模式来计划新的应用程序，如何采用PHP语言编写这些模式，以及如何使用书中介绍的设计模式修正和重构已有的代码块。作者采用专业的、便于使用的格式来介绍相关的概念，自学成才的编程人员与经过更多正规培训的编程人员
- 不要在
Notify中同步执行所有回调——否则一个慢 handler 会拖垮整个事件流 -
sync.Map的Load返回interface{}，类型断言必须检查ok，否则 panic - 注销逻辑需额外实现（例如返回一个
unsubscribe函数），且要考虑并发安全
避免在结构体字段里直接存 []func() 导致内存泄漏
常见错误是把观察者切片作为结构体字段，并在方法中不断 append：
type Service struct {
onDone []func() // ❌ 没有清理机制，长期运行后 slice 不断增长
}
正确做法是：
- 使用
sync.Map或map[string]map[uintptr]func()（用unsafe.Pointer做 key）配合显式Unsubscribe - 或改用一次性通知：比如用
sync.Once+sync.WaitGroup等待关键事件完成，而非持续监听 - 如果观察者是短期存在的（如 HTTP 请求上下文中的钩子），直接传参闭包更安全，无需全局注册
真正难的不是写出让观察者“能跑”的代码，而是判断哪些通知值得抽象成事件、哪些应该用函数参数或返回值直连——Go 的简洁性往往来自克制，而不是补全设计模式。
