viper.watchconfig() 是唯一触发热重载的入口，但需在 readinconfig() 后立即注册 onconfigchange 回调并手动更新变量（如 unmarshal 到 g_config），否则无反应；监听仅针对实际加载的配置文件，且热重载逻辑需异步、去抖、线程安全。
viper.WatchConfig() 是唯一能触发热重载的入口，但直接调用它不会自动生效——必须配合 viper.OnConfigChange 回调和正确的初始化顺序，否则改了配置文件也没反应。
为什么 viper.WatchConfig() 没反应？
常见错误是：在 viper.ReadInConfig() 之后才调用 viper.WatchConfig()，但没设置回调，或回调里没做实际更新逻辑。Viper 不会自动刷新你已读取的结构体变量（比如 G_CONFIG），它只通知“配置变了”，剩下的得你自己干。
- 必须在
viper.ReadInConfig()成功后立即注册viper.OnConfigChange(func(e fsnotify.Event) { ... }) - 回调函数里要重新调用
viper.Unmarshal(&G_CONFIG)或手动更新全局变量（如G_VIPER.GetString("server.port")） - 确保配置文件路径是绝对路径或工作目录稳定；相对路径在 daemon 模式或 IDE 启动时容易失效
- Linux/macOS 默认监听有效，Windows 上某些 IDE（如 Goland）可能拦截
fsnotify事件，需关闭“safe write”选项
G_VIPER 和 G_CONFIG 的分工陷阱
很多项目定义了两个全局变量：G_VIPER *viper.Viper 和序列化后的 G_CONFIG config.Server。问题在于：热重载后，G_VIPER 内部数据已更新，但 G_CONFIG 还是旧值，后续代码如果只读 G_CONFIG 就完全感知不到变化。
- 要么在
viper.OnConfigChange回调里显式执行viper.Unmarshal(&G_CONFIG) - 要么放弃
G_CONFIG，所有地方统一用G_VIPER.GetString("xxx")等动态取值（适合简单配置） - 注意
viper.Unmarshal不会覆盖未在 YAML 中声明的字段，所以结构体字段要有合理默认值
监听多个配置文件或不同格式时的路径冲突
如果你用 viper.AddConfigPath("./configs") 加了多个路径，又同时放了 app.yaml 和 app.json，viper.ReadInConfig() 会按添加顺序尝试读取，但 viper.WatchConfig() 只监听最后成功加载的那个文件——不是全部。
- 不要依赖多路径 fallback 做热重载，明确指定唯一配置文件路径：
viper.SetConfigFile("./configs/app.yaml") - 若需环境区分（dev/staging/prod），用
viper.SetConfigName(fmt.Sprintf("app-%s", env))+viper.SetConfigType("yaml")，再统一监听该文件 - 避免在
viper.AddConfigPath中混用"./"和"configs/"，工作目录切换时行为不可控
生产环境热重载的隐性成本
开启 viper.WatchConfig() 后，每个配置变更都会触发一次完整的 viper.Unmarshal 和你的回调逻辑，但没人告诉你：这会阻塞主线程，且无法取消。如果回调里做了数据库连接重建、中间件重载等重操作，请求可能卡住。
- 把耗时操作（如重连 DB）放到 goroutine 里异步执行，但要注意并发安全（比如
G_DB替换时加sync.RWMutex） - 配置变更频率高时（如频繁调试），建议加简单去抖：
time.AfterFunc(100 * time.Millisecond, func(){...}) - 线上禁用热重载更稳妥；开发期用，上线前通过构建参数固化配置，避免运行时不确定性
真正难的不是让 Viper 监听文件，而是让整个应用的状态（DB 连接、日志级别、路由开关）跟着配置原子性地切换过去——这部分没法靠库自动完成，得你一条条对齐。
