Go微服务配置热更新需手动实现：viper.WatchConfig仅通知变更，须配合SetConfigType、OnConfigChange及ReadInConfig重载；动态配置（如日志等级）可热更，静态项（如服务名）必须重启；资源（DB连接池、HTTP客户端）需主动调用API或重建实例，并保障线程安全与可观测性。
Go 微服务中 config 包不支持热更新，必须自己接管
Go 标准库 flag 和常见第三方包（如 viper 默认模式、koanf 静态加载）都只在启动时读取一次配置。哪怕文件被修改，viper.WatchConfig() 也仅是监听变更并触发回调——它不会自动刷新结构体字段或重载服务行为。热更新不是“开个开关”就能生效，而是要你明确决定：哪些配置可变、何时重载、重载时是否中断请求、旧配置如何平滑下线。
viper.WatchConfig() 必须配 SetConfigType + OnConfigChange 才有效
很多项目直接调 viper.WatchConfig() 却没反应，根本原因是没设置配置类型或没注册回调。Watch 本身不解析内容，只通知“文件变了”，后续动作全靠你写。
-
viper.SetConfigType("yaml")或viper.SetConfigType("json")必须在ReadInConfig()前调用，否则Unmarshal()会失败 -
viper.OnConfigChange()回调里必须显式调viper.ReadInConfig()（或viper.Unmarshal()）来重新加载数据 - 回调函数运行在独立 goroutine，不能直接操作全局变量而不加锁；若配置映射到 struct，需用指针+互斥锁更新
viper.SetConfigName("config")
viper.SetConfigType("yaml")
viper.AddConfigPath("./configs")
viper.ReadInConfig()
viper.WatchConfig()
viper.OnConfigChange(func(e fsnotify.Event) {
log.Println("Config file changed:", e.Name)
if err := viper.ReadInConfig(); err != nil {
log.Printf("Failed to reload config: %v", err)
return
}
// ⚠️ 此处需手动同步到 runtime 状态，例如：
mu.Lock()
globalCfg = viper.AllSettings()
mu.Unlock()
})
数据库连接池、HTTP 客户端等资源不能靠“重读配置”自动重建
热更新 ≠ 服务重启。改了 db.max_open_conns 不会自动调 sql.DB.SetMaxOpenConns()；改了 http.timeout 也不会让已有 http.Client 生效新值。这些必须你主动响应配置变更，调对应方法或重建实例。
- 连接池参数（
SetMaxOpenConns、SetMaxIdleConns）支持运行时调整，直接调即可 - HTTP 超时、重试策略等不可变字段（如
http.Client.Timeout）必须新建 client 实例，并原子替换引用（配合sync/atomic或 mutex） - gRPC 连接、Redis 客户端等第三方库大多不支持热更新，需自行封装 reconnect 逻辑或优雅关闭后重建
配置项必须分级设计：静态 vs 动态 vs 重启敏感
不是所有配置都适合热更新。强行对 service.name 或 grpc.port 做热更新，只会引发注册中心不一致、端口冲突或监听失败。上线前就得划清边界：
立即学习“go语言免费学习笔记（深入）”；
- 静态项：服务名、监听地址、TLS 证书路径——只能启动时读取，改了必须重启
- 动态项：日志等级、熔断阈值、缓存 TTL、限流 QPS——应支持热更新，并有配套的 metrics 上报验证是否生效
- 半动态项：DB 连接串（host/port）、下游服务地址——可热更新，但需配合健康检查与连接重建，避免雪崩
最易被忽略的是配置变更的可观测性：没有日志记录谁改了哪一项、旧值/新值是什么、是否触发了资源重建——等于裸奔。每次 OnConfigChange 至少记一条 structured log，带上 viper.AllKeys() 差异比对结果。
