配置热更新思路与注意点

一句话结论：热更新的本质是“不改代码、不重启进程地替换运行参数”。实现上有四条路：定时轮询重读文件、SIGHUP 信号触发、文件监听（viper.WatchConfig + OnConfigChange，底层 fsnotify）、订阅配置中心推送。核心注意点有三个：① 新配置必须解析成不可变快照后整体原子替换（atomic.Pointer/RWMutex），保证并发读永远看到完整的新旧版本；② 校验失败要回滚并告警，绝不能半套配置生效；③ 不是所有配置都能热更——监听端口、DB 连接串、TLS 证书这类需要重建组件的配置要明确“只读一次或走重启”。

要点

• 快照模式：读方一次取指针再使用，期间配置不会再变；写方只在收到变更后生成新快照发布。
• 变更校验：先解析+Validate 新配置，失败则保留旧快照并输出错误日志/告警；成功才发布。
• 范围划分：把配置分成“可热更”（开关、阈值、限流参数、日志级别、名单）与“需重建/重启”（端口、监听、DSN、证书、路由表）。
• fsnotify 局限：容器 overlay 文件系统、网络盘、部分挂载场景事件不可靠，通常配合轮询兜底或直接用配置中心。
• 多实例一致性：配置中心推送时各实例到达有先后，灰度环境按实例分批发布更稳。
• 变更后动作：回调里可能要做“重建限流器/连接池、刷新规则缓存”等副作用，副作用要幂等且可失败重试。
• 变更留痕：把“哪个 key 从什么值改成什么值、谁触发”记录到日志/审计，出问题可回溯。
• 分级管理：高频开关（功能开关、名单）走配置中心即时下发，低频参数走文件加载，别一刀切全走同一条链路。

viper 监听示例

viper.WatchConfig()
viper.OnConfigChange(func(e fsnotify.Event) {
    var next Config
    if err := viper.Unmarshal(&next); err != nil { // 校验失败：回滚
        log.Error("配置解析失败，沿用旧配置", "err", err)
        return
    }
    cfgPtr.Store(&next) // atomic 发布新快照，读方无锁取用
    rebuildRateLimiter(next.Limits) // 副作用重建
})

// 读方：一次取快照，多次使用不撕裂
cfg := cfgPtr.Load()
if cfg.FeatureFlags.NewUI { ... }

追问记忆点

• 追问：热更新时请求会读到“改了一半”的配置吗？——会，如果不做快照替换而直接改共享 map/struct；解法是整体替换指针，旧请求用旧快照、新请求用新快照，逻辑上完整。
• 追问：端口为什么不能热更？——监听器在启动时创建并绑定，改端口需要重建 listener 并迁移连接，代价接近重启，收益低。
• 追问：WatchConfig 的坑？——fsnotify 事件在容器/网络盘不可靠，别把可靠性全押在它上面，重要配置建议轮询兜底或配置中心。
• 记忆点：快照原子替换 + 校验回滚 + 区分可热更/需重建 + 监听事件要兜底，四件事缺一不可。