Go 语言本身不支持运行时函数体热替换，所谓“热加载”在实际项目中基本只有两类可靠路径：配置热更新（用 fsnotify + atomic.Value）和进程级重启（用 fresh、gin 等工具）。真去 patch 内存或动态加载 plugin，不是卡版本就是挂生产。
为什么 viper.WatchConfig() 单独调用没反应
它只注册监听器，不阻塞主线程，也不自动重读配置。调完 viper.WatchConfig() 后如果 main() 立即返回，整个进程就退出了，监听根本没机会触发。
-
viper.AddConfigPath()和viper.SetConfigName()必须在WatchConfig()前完成，否则回调里viper.ReadInConfig()会报Config File Not Found -
OnConfigChange回调里不做viper.ReadInConfig()，缓存永远不变；不做viper.Unmarshal()，结构体字段也不会更新 - 必须确保程序长期存活：启动 HTTP server（
http.ListenAndServe()），或加select {}（仅调试）
用 fsnotify 监听配置文件变更最靠谱
fsnotify 封装了 Linux 的 inotify、macOS 的 FSEvents、Windows 的 ReadDirectoryChangesW，避免轮询缺陷。但要注意编辑器保存行为——Vim/VS Code 常先写临时文件再原子替换，触发的是 fsnotify.Create + fsnotify.Remove，不是 Write。
- 监听路径必须是**目录**，不能是单个文件（macOS 下可能漏事件）
- 收到
fsnotify.Write或fsnotify.Create后，建议加 10–100ms 延迟再 reload，防止读到半截内容 - 监听事件类型只关注
fsnotify.Write和fsnotify.Chmod，覆盖主流编辑器保存行为 - 监听路径必须是配置文件的**绝对路径**，不能监听整个目录——否则子目录变更也会误触发
配置热更新必须用 atomic.Value + 深拷贝保障并发安全
业务代码统一通过 conf := globalConf.Load().(*Config) 读取，禁止缓存该指针——对象可能被下一次更新回收。配置结构体必须全字段导出，不含 sync.Mutex 或闭包等不可复制字段，否则 unsafe.Pointer 转换会崩溃。
- 每次成功解析后才调用
globalConf.Store(&newCfg)；加载失败直接跳过，旧配置继续生效 - 如果配置含切片或 map，确保它们是深拷贝或不可变结构，否则并发读写仍可能 panic
- 容器环境里
inotify资源耗尽是静默失败：Docker 默认inotify.max_user_watches只有 8192，一个服务监听几十个配置文件就容易打满 - 宿主机查限制：
cat /proc/sys/fs/inotify/max_user_watches；Docker 启动时加--sysctl fs.inotify.max_user_watches=524288
真正难的从来不是“怎么让配置变”，而是“怎么确保所有 goroutine 在任意时刻读到的都是完整、合法、一致的状态”。原子指针替换只是手段，背后是对数据生命周期和并发访问边界的清醒判断。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
