etcd clientv3 watch 必须起 goroutine 消费事件，否则因 channel 缓冲区满（默认100条）导致事件丢失；需先 get 全量配置再 watch，并在回调中再次 get 校验，配合 atomic.value 原子更新结构体，避免半新半旧状态。
etcd clientv3 Watch 必须起 goroutine 消费，否则事件全丢
Watch 收不到变更不是 etcd 问题，而是 Go 客户端没主动读 channel。client.Watch() 返回的 clientv3.WatchChan 是阻塞只读 channel，缓冲区默认 100 条，满后新事件直接丢弃——你看到“配置没更新”，其实是事件早被吞了。
- 必须用
go func() { for range watchChan { ... } }()单独起 goroutine 持续消费，不能放在主流程里同步 for-range，否则服务启动卡住 - channel 关闭时
ok == false是唯一可靠信号，要主动重建 watch，etcd client 不会自动重连 - 传给
Watch()的context.Context生命周期要够长，别用context.WithTimeout(ctx, time.Second)包整个监听循环
热更新配置必须原子替换，别直接赋值 struct
直接写 config = newConfig 会导致其他 goroutine 读到字段级不一致状态：比如 DB.Host 还是旧值，DB.Timeout 却已是新值——这种半新半旧比完全不更新更危险。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 推荐用
sync/atomic.Value：每次构造全新不可变结构体，调用configStore.Store(&Config{})；读取时configStore.Load().(*Config) - 结构体所有字段必须导出（大写开头），且禁止提供 setter 方法，确保“构造即冻结”
- 不要在 watch 回调里直接重启 HTTP server 或重连 DB 连接池——只写入通知 channel，由主逻辑异步处理
首次加载 + 持续监听要分两步，防竞态空配置
服务启动时如果只 Watch 不 Get，可能因网络延迟或 etcd 启动慢，导致业务代码拿到空配置就 panic。Watch 本身不保证首次值到位。
- 先调一次
client.Get(ctx, key)拉全量配置，解析成功后再启动 Watch - Watch 到变更后，**必须再调一次
client.Get()全量拉取校验**，避免网络抖动丢失事件导致本地状态漂移 - key 路径建议用前缀隔离环境，例如
/services/user-svc/production/，别依赖启动参数传--env=prod再拼路径
别把 Viper 当 etcd 客户端用，它不支持真 Watch
viper.AddRemoteProvider("etcd", ...) 和 viper.WatchRemoteConfig() 都是伪热更新：前者只在 ReadRemoteConfig() 时拉一次；后者本质是轮询 HTTP 接口，延迟高、连接泄漏、无事件驱动。
- 正确做法：用原生
clientv3监听变更 → 解析为 struct → 存进atomic.Value或sync.Map→ 业务层通过封装好的config.GetDBTimeout()访问 - Viper 只负责加载本地文件（如 config.yaml）或环境变量，作为 fallback 或默认值来源，不参与远程变更链路
- 敏感字段（如密码）仍走环境变量注入，etcd 存的 value 建议用 JSON 结构，避免裸字符串解析失败静默跳过
ev.Kv != nil && len(ev.Kv.Value) > 0，再做 json.Unmarshal(bytes.TrimSpace(...), &v)，否则空值或乱码会直接 panic 或覆盖成零值。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
