viper.WatchConfig()对Apollo完全无效，因其仅监听本地文件系统变化，无法感知Apollo通过长轮询或WebSocket推送的远程配置变更；必须使用agollo.WithOnChange()注册回调，在其中手动调用viper.Set()更新内存并处理命名空间、并发安全及下游组件重载。
viper.WatchConfig() 对 Apollo 完全无效，必须用 agollo.WithOnChange() 主动桥接回调并手动更新内存。
为什么 viper.WatchConfig() 在 Apollo 场景下静默失效
它只监听本地文件系统事件，根本收不到 Apollo 的长轮询或 WebSocket 推送。调了 viper.WatchConfig() 后改配置，viper.Get("db.host") 仍返回旧值，日志里连 warning 都没有。
- Apollo 变更是远程推送，Viper 没订阅能力，也不拉新值
- 常见误操作：启动时调了
viper.WatchConfig()就以为热更新已就绪 - 真正生效的是 Apollo SDK 自己的缓存，但 Viper 不知道、不感知
必须用 agollo.WithOnChange() 注册回调并写入 Viper
社区活跃、Go 1.21+ 兼容的客户端是 github.com/philchia/agollo（官方 apollo-client-go 已归档且 checksum 失败）。热更新不是“自动同步”，是你在回调里把新值塞进 Viper 内存。
- 初始化 client 时显式传
agollo.WithNamespaces("application", "mysql.yml")，后缀必须和 Apollo 控制台 namespace 名完全一致 - 注册回调：
agollo.WithOnChange(func(*agollo.ChangeEvent) { ... }) - 遍历
ChangeEvent.Changes，对每个key调viper.Set(key, newValue)；Apollo 的db.host=127.0.0.1对应 Viper 的"db.host"，不是下划线格式 - 若 key 来自
mysql.yml，想让 Viper 放进mysql下层，得手动拼成"mysql.db.host"
多 namespace 冲突与并发读写怎么防
Apollo 支持多个 namespace，但 Viper 默认扁平化存储。不加处理，application 和 mysql.yml 里的同名 timeout 会互相覆盖；更危险的是裸写 viper.Set()，业务 goroutine 正在调 viper.GetInt("timeout") 可能读到半更新状态。
- 推荐做法：每次回调都解析出全新
*Config结构体，用sync/atomic.Value原子替换，业务侧统一走globalConf.Load().(*Config) - 命名空间隔离建议：启动时只加载
application到 Viper 根，mysql.yml单独用agollo.GetConfig("mysql.yml").GetYAML()解析为map，不混进 Viper - 别漏掉
viper.SetConfigType("yaml")—— 必须在viper.ReadInConfig()之前调，否则反序列化失败
配置变了，下游组件如 DB 连接池、Logger 却没反应
热更新只负责把新值写进内存，不会自动触发 logrus.Level 变更、*sql.DB 参数重置或 HTTP client timeout 刷新。这些必须你手动 hook。
立即学习“go语言免费学习笔记（深入）”；
- DB 连接池重建：在回调里新建
sql.Open()实例，原实例需显式Close() - Logger 级别变更：调
logrus.SetLevel()，注意logrus.StandardLogger()是全局单例 - HTTP client timeout：重建
&http.Client{Timeout: cfg.HTTP.Timeout}，旧 client 不会自动更新 - 所有 hook 动作必须放在回调内，且确保执行顺序——先更新 Viper，再刷新下游组件
atomic.Value 替换结构体、以及下游组件的手动重载——这三步缺一不可，否则看似配置更新了，服务行为却没变。 
