Go 中用 sync.Map 实现观察者注册表是因为普通 map 并发写会 panic；sync.Map 线程安全、读多写少更轻量，LoadOrStore 原子操作避免重复注册，Range 快照语义合理，配合 channel 事件驱动实现高效配置通知。
Go 里用 sync.Map 实现观察者注册表，为什么不能用普通 map
并发写普通 map 会直接 panic："fatal error: concurrent map writes"。观察者模式的核心是多个 goroutine 可能同时调用 Subscribe 或 Unsubscribe，必须线程安全。
虽然 sync.RWMutex + map 也能做，但 sync.Map 对读多写少场景更轻量，尤其适合配置变更这种“订阅频繁、修改稀疏”的行为。
-
sync.Map的LoadOrStore能原子完成“查+存”，避免重复注册同一回调 - 别把回调函数本身塞进
sync.Map值里再反射调用——性能差且难 debug，直接存函数值即可 - 注意
sync.Map的Range是快照语义，遍历时新增的 observer 不会被本次通知覆盖，这是合理行为，不是 bug
配置变更通知必须用 channel + select，不能用全局变量轮询
轮询（比如每 100ms 查一次 config.Version）浪费 CPU，延迟不可控，且无法感知瞬时变更。真正的动态生效依赖事件驱动。
典型结构是：一个中心 notifyCh chan ConfigEvent，所有 Subscribe 返回的 chan ConfigEvent 都由后台 goroutine 从 notifyCh 复制分发。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- channel 容量至少设为 1，否则通知可能丢失（尤其在 handler 处理慢时）
- 不要在 handler 里直接阻塞调用外部服务（如 HTTP 请求），应起新 goroutine 或加超时，否则会卡住整个通知流
- 如果配置中心用 etcd/viper+watch，它的底层 watch event 已经是 channel，别再套一层无意义的 for-select
viper.WatchConfig() 的坑：只监听文件，不自动适配远程配置源
viper.WatchConfig() 默认只对本地文件（viper.SetConfigFile）生效。如果你用 viper.AddRemoteProvider("etcd", "http://127.0.0.1:2379", "/config")，它根本不会触发 OnConfigChange 回调。
原因在于 viper 的 watch 机制和远程 provider 是两套逻辑：前者基于 fsnotify，后者需手动调用 WatchRemoteConfig 并自己处理 event。
- 远程配置必须显式调用
viper.WatchRemoteConfig()，且要配合viper.OnConfigChange手动触发 reload -
WatchRemoteConfig内部会启一个 goroutine 持续 long polling 或 watch，别在 init 里调完就不管——它不返回 error，失败时静默重试 - 如果同时用了本地文件 + 远程 source，viper 会 merge，但 watch 行为互不影响，得分别处理
分布式环境下，单机 observer 收不到其他节点的配置变更
观察者模式天然单机。A 节点收到 etcd 配置更新并通知了本地所有 observer，B 节点完全不知情——除非你把“配置变更”本身当作一个业务事件，通过消息队列或 pub/sub 同步到所有节点。
这不是 Go 语言或设计模式的问题，是分布式系统的基本约束：内存状态不跨进程共享。
- 别指望
sync.Map或 channel 能穿透机器边界 - 真正解法是分层：底层用 etcd/zookeeper 做统一配置存储，上层每个节点独立实现“watch → 解析 → 本地通知 observer”闭环
- 如果业务要求强一致（比如灰度开关必须全集群秒级同步），就得引入额外协调机制，比如 Redis Pub/Sub 或 Kafka，但这已超出观察者模式范畴
最常被忽略的一点：配置结构体字段的零值语义。比如 Timeout int 从 30 改成 0，是想关掉超时，还是配置写错了？observer 拿到新 struct 后，得结合字段 tag（如 json:",omitempty"）或显式标记位判断意图，不能只比对内存地址或浅层相等。
