Go无内置热更新机制，需用fsnotify监听文件变化或viper支持多后端并手动处理运行时生效逻辑，关键在配置加载、并发安全、fail-safe及业务组件响应变更。

Go 本身没有内置的配置热更新机制，flag、os.Getenv 或静态 init() 加载的配置在进程启动后就固定了。要实现真正的“热更新”，必须主动监听变化并重新加载配置结构体，同时确保运行中的组件（如 HTTP handler、DB client、日志级别）能感知并响应变更。

用 fsnotify 监听配置文件变化

这是最轻量、可控性最强的方式，适合本地文件（JSON/YAML/TOML）场景。核心是用 fsnotify 库监听文件系统事件，避免轮询开销。

• 仅监听 fsnotify.Write 和 fsnotify.Chmod 事件（部分编辑器保存时先 chmod）
• 收到事件后，用互斥锁保护配置解析过程，防止并发 reload 导致状态不一致
• 解析失败时保留旧配置，记录错误但不 panic —— 热更新必须 fail-safe
• 注意：Windows 下某些编辑器（如 VS Code）保存 YAML 时会先写临时文件再 re

  

  name，需监听所在目录而非单个文件，或改用 fsnotify.Create + 文件名匹配

package main

import (
    "log"
    "os"
    "sync"
    "gopkg.in/yaml.v3"
    "github.com/fsnotify/fsnotify"
)

type Config struct {
    Port     int    `yaml:"port"`
    Timeout  int    `yaml:"timeout"`
    Database string `yaml:"database"`
}

var (
    config     Config
    configMu   sync.RWMutex
    watcher, _ = fsnotify.NewWatcher()
)

func loadConfig(path string) error {
    data, err := os.ReadFile(path)
    if err != nil {
        return err
    }
    return yaml.Unmarshal(data, &config)
}

func watchConfig(path string) {
    defer watcher.Close()
    if err := watcher.Add(path); err != nil {
        log.Fatal(err)
    }
    for {
        select {
        case event, ok := <-watcher.Events:
            if !ok {
                return
            }
            if (event.Op&fsnotify.Write == fsnotify.Write) || 
               (event.Op&fsnotify.Chmod == fsnotify.Chmod) {
                if err := loadConfig(path); err != nil {
                    log.Printf("reload config failed: %v", err)
                    continue
                }
                log.Println("config reloaded")
            }
        case err, ok := <-watcher.Errors:
            if !ok {
                return
            }
            log.Printf("watcher error: %v", err)
        }
    }
}

用 viper 支持多种后端 + 自动热重载

viper 是 Go 社区最常用的配置库，它封装了文件监听、环境变量、远程 etcd/Consul 等能力。但要注意：它的 WatchConfig() 默认只支持本地文件，且必须手动调用 viper.Get* 才能获取最新值 —— 它不自动刷新已读取的变量副本。

• 调用 viper.WatchConfig() 前，必须先设置 viper.SetConfigFile() 或 viper.AddConfigPath()
• 监听回调中应触发业务逻辑的更新（例如重置 http.Server.ReadTimeout），不能只依赖 viper.GetString() 后续调用
• 若用 etcd，需启用 viper.AddRemoteProvider("etcd", "http://127.0.0.1:2379", "/config") 并调用 viper.ReadRemoteConfig()，但 etcd 的 watch 需自行实现（viper 不自动处理）
• 多个微服务共用同一份配置时，建议加前缀隔离，如 viper.SetKeyDelim(".") + 读取 viper.Sub("service.auth")

配置变更如何安全影响运行时行为

热更新不是“换掉一个 struct 就完事”。真正难的是让正在处理请求的模块感知变更，比如日志级别变低后新日志立即生效，或 DB 连接池大小调整后不再新建连接。

• HTTP server 的 ReadTimeout/WriteTimeout 只在启动时读取一次，需重建 http.Server 实例（配合 graceful shutdown）
• 日志级别（如 zerolog.GlobalLevel()）可直接调用 zerolog.SetGlobalLevel()，它是原子更新
• 数据库连接池（*sql.DB）的 SetMaxOpenConns 和 SetMaxIdleConns 是运行时生效的，无需重启
• 避免在 handler 中缓存 viper.GetInt("port") 这类值 —— 每次都应调用 getter，或用 channel + goroutine 广播变更事件

环境变量与配置中心的取舍

容器化部署下，环境变量（os.Getenv）看似简单，但它无法热更新 —— Pod 重启才生效。而配置中心（Nacos / Apollo / etcd）虽支持推送，但引入了外部依赖和网络故障面。

• 开发/测试环境优先用文件 + fsnotify，零外部依赖，调试直观
• 生产环境若已接入 Nacos，可用其 SDK 的 ListenConfig 方法注册回调，但务必设置超时和重试（Nacos 长轮询可能中断）
• 不要混合使用：禁止“环境变量覆盖配置文件”的动态 fallback 逻辑，会导致配置来源不可追溯
• 所有配置项必须有明确默认值，并在程序启动时做合法性校验（如 Port > 0 && Port ），热更新时也应复用同一套校验逻辑

热更新真正的复杂点不在监听文件或拉取远端，而在于业务代码是否为“可变配置”做了准备 —— 是否所有依赖配置的地方都通过统一 accessor 获取，是否每个可变参数都有对应的 runtime 控制接口。没做这些，reload 之后配置变了，程序行为却没变。