fsnotify默认不递归监听，需显式add每个配置文件路径；注意inotify句柄限制、线程安全（用sync.rwmutex或原子指针替换）、事件过滤（排除.swp等）及编辑器rename行为导致的create/remove事件，并添加debounce延迟。
fsnotify 能监听配置文件变更，但默认不递归
直接用 fsnotify.NewWatcher() 只监听单个文件或目录一级，改了子目录里的 config.yaml 不会触发事件。常见现象是：配置文件明明保存了，程序却没 reload，日志里也看不到任何通知。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
watcher.Add()显式添加每个配置文件路径，比如"./config.yaml"、"./conf/db.toml"，别只加"./config"目录指望它自动覆盖子项 - 如果配置分散在多级目录，自己写个递归遍历 +
watcher.Add()，别依赖fsnotify的“智能” - Linux 下 inotify 有句柄数限制，
watcher.Add()太多文件可能报too many open files，记得用ulimit -n检查并调高
配置解析与热加载必须线程安全，否则 panic
收到 fsnotify.WriteEvent 或 fsnotify.CreateEvent 后立刻去解析新文件，再赋值给全局配置变量——这是最常见 panic 来源。多个 goroutine 同时读写同一个结构体（尤其是含 map、slice 字段时）会触发 data race。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
sync.RWMutex包裹配置读写，写操作（reload）用Lock()，读操作（业务逻辑中取cfg.DB.Host）用RUnlock() - 别在 reload 时原地修改旧 config struct，而是 new 一个新实例，解析完再原子替换指针，例如：
atomic.StorePointer(&configPtr, unsafe.Pointer(newCfg)) - 避免在 reload 过程中调用可能阻塞或重入的函数（比如又去读一次文件、发 HTTP 请求），否则可能卡住整个监听 goroutine
viper 自动热重载和 fsnotify 手动控制的区别很关键
viper.WatchConfig() 看似省事，但它内部用的就是 fsnotify，且默认开启递归监听——这反而容易出问题：比如编辑器临时生成 .config.yaml.swp，viper 会误触发 reload，而此时文件内容不完整，解析失败直接 crash。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 禁用
viper.WatchConfig()，自己控制fsnotify事件过滤 - 收到事件后，先检查
event.Name是否匹配目标文件名，再判断event.Op&fsnotify.Write == fsnotify.Write，排除Chmod、Remove等无关操作 - 加个简单校验：读取新文件前先
os.Stat()确认存在且非空，解析失败时打印错误但不 panic，保留旧配置继续运行
测试热加载必须覆盖文件编辑器真实行为
用 echo "key: val" > config.yaml 测试成功，不等于上线后能跑通。VS Code、vim、nano 写文件实际走的是“rename 临时文件”流程，触发的是 CreateEvent + RemoveEvent，不是简单的 WriteEvent。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 测试时用编辑器真实保存一次，别只靠
touch或echo - 监听
fsnotify.Create和fsnotify.Write两种事件，但对Create要加文件名白名单过滤，防止监听到 .swp/.tmp 文件 - 加个 100ms 延迟 debounce：收到事件后
time.AfterFunc(100 * time.Millisecond, reload)，避免编辑器多次写入触发多次 reload
真正难的不是监听到变化，而是判断“这次变化是否可信、是否已完成、是否值得 reload”。文件系统事件太底层，编辑器行为太多样，中间差的那层语义判断，得自己补全。
