fsnotify.add("config.yaml")不触发是因为编辑器原子写入导致inode失效；必须监听父目录并过滤文件名，用os.stat排除临时文件，以atomic.value或sync.rwmutex安全替换配置，并显式调用组件更新接口。
为什么 fsnotify.Add("config.yaml") 总是不触发
因为主流编辑器（VS Code、Sublime、vim swap 模式）默认用 atomic write：先写 config.yaml.tmp，再 rename 覆盖原文件。fsnotify 监听的是 inode 或路径句柄，旧路径失效后事件就丢了。
- 监听单个文件只对
echo "x" >> config.yaml这类追加操作有效 - 正确做法是监听父目录（如
"./conf"），再用filepath.Base(event.Name)过滤出目标文件名 - 收到
event.Op后必须立刻os.Stat(event.Name)，排除.swp、.tmp等临时文件干扰
如何安全替换正在被并发读取的配置结构体
直接赋值 cfg = newCfg 会导致多个 goroutine 读到部分新、部分旧的中间态，甚至 panic。Go 没有引用绑定机制，内存拷贝 ≠ 原子可见性。
- 推荐用
atomic.Value：声明var globalConf atomic.Value，加载成功后调globalConf.Store(&newCfg)，读取时globalConf.Load().(*Config) - 若用
sync.RWMutex，所有读操作必须包裹mu.RLock()/mu.RUnlock()，reload 时用mu.Lock()构造新实例再替换 - 绝不在 reload 函数里做耗时操作（如 DB 连接测试、HTTP 请求），校验通过后应极短时间内完成原子写入
配置更新了，但 DB 连接池/日志级别没变，为什么
fsnotify 和 viper 只负责把 YAML 解析成 Go 结构体，下游组件是否响应新值，完全取决于你有没有显式调用它们的更新接口。
- DB 连接池大小变更需调
db.SetMaxOpenConns()和db.SetMaxIdleConns()—— 这两个方法线程安全，可直接生效 - 日志级别（如 zap）要调
logger.Level().SetLevel(zapcore.Level)，不是改配置字段就完事 - HTTP Server 的
ReadTimeout、WriteTimeout等字段无法热更，只能 graceful restart，不属于“配置热加载”范畴 - 自定义逻辑（如限流阈值）建议封装成带 mutex 的 getter 方法，内部检查是否需 reload，而非暴露原始字段
监听路径权限与内核限制容易被忽略
监听失败往往静默发生，程序继续跑但再也不触发 reload，问题最难排查。
-
watcher.Add(path)返回 error 必须检查：路径不存在、无 read 权限都会立即失败 - 监听目录时，进程需对目录有
read权限（否则无法获取子项变更）；监听单个文件只需read权限 - Linux 上受
/proc/sys/fs/inotify/max_user_watches限制，大批量监听可能报no space left on device，需提前调整该值 - 符号链接默认不跟随，要监听目标文件得先
filepath.EvalSymlinks解析再Add
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
