热更新配置必须用 watcher 持续监听并安全替换，禁用重复解析；viper.watchconfig() 不支持嵌套 map 自动更新，需在回调中显式调用 viper.unmarshal(&cfg)；生产环境推荐 etcd + remoteprovider，配合 configch 事件驱动通知业务逻辑。
配置热更新必须用 Watcher，别依赖重启
Go 服务启动后，os.Args 和初始 flag.Parse() 或 viper.ReadInConfig() 都只执行一次。想改配置不重启，核心是监听文件/远程源变化并触发重载逻辑——不是“读两次”，而是“持续监听+安全替换”。常见错误是直接在 handler 里反复调用 viper.Unmarshal()，这会导致并发读写冲突或结构体字段未同步清空。
viper.WatchConfig() 的坑：默认不支持嵌套 map 更新
viper.WatchConfig() 能监听文件变更并触发回调，但它的默认行为只重载顶层键值，对嵌套结构（如 database.connections[0].timeout）可能失效。尤其当配置含 slice 或 map 时，旧引用残留容易引发 panic 或逻辑错乱。
- 必须在 Watch 回调里显式调用
viper.Unmarshal(&cfg)，而不是只靠viper.Get() - 确保
cfg是指针，且结构体字段带正确 tag，例如yaml:"timeout" - 若用
viper.SetConfigType("yaml")，务必在WatchConfig()前完成，否则首次变更会报Unsupported Config Type ""
生产环境建议用 etcd + viper.RemoteProvider
文件监听适合开发，但线上多实例时，文件更新无法广播。用 viper.AddRemoteProvider() 连接 etcd 是更稳妥的方案，它内置长轮询和缓存机制，避免每个实例都直连配置中心。
- 初始化时需调用
viper.ReadRemoteConfig()拉取一次，再启用viper.WatchRemoteConfig() - etcd key 路径要带前缀，比如
/service/app/config，viper 会自动解析子路径为嵌套结构 - 注意 etcd 的 lease TTL 设置，避免连接断开后配置被意外删除
更新后如何安全通知业务逻辑？用 channel + sync.Once
配置变了，数据库连接池、超时阈值、开关状态这些依赖项必须响应。直接全局变量赋值有竞态风险，推荐用事件驱动方式。
- 定义一个
configCh chan struct{}，Watch 回调里select { case configCh 防止阻塞 - 各模块启动时起 goroutine 监听该 channel，收到信号后调用自身
reload()方法 - 对一次性生效的配置（如日志级别），用
sync.Once包裹初始化逻辑，避免重复加载
最常被忽略的是：配置更新后，旧连接、缓存、定时器不会自动销毁。你得自己实现清理逻辑，比如调用 db.Close() 再重建连接池——viper 不管这部分。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
