viper需手动启用监听并注册OnConfigChange回调，且WatchConfig()须在ReadInConfig()后调用、置于goroutine中；etcd watch需处理空事件、前缀监听及手动反序列化；并发更新须用锁或原子操作避免panic；环境变量和flag不可热更新。
用 viper 监听文件变化触发配置重载
viper 默认不自动热更新，必须手动启用监听并注册回调。常见错误是只调用 viper.WatchConfig() 却没设 viper.OnConfigChange，结果文件变了但程序无反应。
关键点：监听只对本地文件有效（如 config.yaml），不适用于远程配置中心；且首次加载后才开始监听，所以务必在 viper.ReadInConfig() 之后调用 WatchConfig()。
- 必须在 goroutine 中运行
viper.WatchConfig()，否则会阻塞主线程 -
回调函数里应重新调用
viper.Unmarshal(&cfg)同步结构体字段，不能只靠viper.Get() - 注意并发安全：如果多个地方读配置，建议用
sync.RWMutex包裹配置结构体写入
go
func initConfig() {
viper.SetConfigName("config")
viper.SetConfigType("yaml")
viper.AddConfigPath("./conf")
if err := viper.ReadInConfig(); err != nil {
log.Fatal(err)
}
<pre class='brush:php;toolbar:false;'>viper.OnConfigChange(func(e fsnotify.Event) {
log.Println("Config file changed:", e.Name)
if err := viper.Unmarshal(&config); err != nil {
log.Printf("Failed to unmarshal new config: %v", err)
return
}
})
viper.WatchConfig()}
etcd + watch 实现分布式配置热更新
单机文件监听无法满足多实例场景，etcd 的 Watch 接口是更通用的选择。核心不是“轮询”，而是建立长连接接收变更事件。
立即学习“go语言免费学习笔记（深入）”；
容易踩的坑：直接用 clientv3.New() 创建 client 后未设置超时或重连策略，导致网络抖动时 watch 断开却不恢复；另外，watch 返回的 resp.Events 可能为空（例如租约续期事件），需判空再处理。
- 推荐使用
clientv3.WithRequireLeader()避免读到旧数据 - watch 路径建议带前缀（如
/service/app/），便于批量监听整个配置树 - 变更后仍需主动反序列化（如
json.Unmarshal(resp.Events[0].Kv.Value, &cfg)），viper 不自动介入 etcd 流程
go
cli, _ := clientv3.New(clientv3.Config{
Endpoints: []string{"http://127.0.0.1:2379"},
DialTimeout: 5 * time.Second,
})
ctx, cancel := context.WithCancel(context.Background())
defer cancel()
<p>watchCh := cli.Watch(ctx, "/service/app/", clientv3.WithPrefix())
for resp := range watchCh {
for _, ev := range resp.Events {
if ev.Type == clientv3.EventTypePut {
json.Unmarshal(ev.Kv.Value, &config)
log.Println("Config updated from etcd")
}
}
}</p>避免热更新引发的运行时 panic
配置字段被其他 goroutine 并发读取时，直接赋值结构体会导致读写竞争。典型现象是 fatal error: concurrent map writes 或字段值“部分更新”——新旧配置混在一起。
最轻量的解法不是锁整个结构体，而是按需保护敏感字段或使用原子操作。例如数据库连接池大小变更，应先关闭旧连接池、再新建，而不是直接改 cfg.DB.PoolSize 后期待下游自动感知。
- 不要在配置结构体里放指针或 map/slice 类型字段，除非你明确控制其生命周期
- HTTP server 的
ReadTimeout等字段更新后，需调用srv.SetKeepAlivesEnabled(false)再srv.Close()重启监听（无法原地修改） - 日志级别这类低开销配置，可用
atomic.Value存储，读取时Load().(zap.AtomicLevel)
环境变量和命令行参数能否热更新？
不能。环境变量和 flag 在进程启动时已固化，操作系统不提供运行时修改接口。强行重读 os.Getenv() 或 flag.Lookup() 只能得到初始值。
如果业务强依赖“动态环境切换”，唯一办法是把它们转为配置中心条目（如 etcd 中存 /env/DEBUG=true），再通过上述 watch 机制加载。否则只能接受：环境变量 = 静态部署标识，配置热更新 = 运行时可变参数。
真正复杂的是配置语义冲突——比如热更新把 log_level 从 info 改成 debug，但日志库内部没有暴露 level 设置接口。这种时候，不是热更新没做对，而是组件本身不支持运行时调整。
