fsnotify.Add只监听单层目录，因Watcher设计为路径粒度且底层inotify/kqueue不递归；需手动遍历子目录逐个Add，推荐用filepath.WalkDir，并在Create事件中延迟校验后动态Add新目录。
fsnotify.Add 为什么只监听单层目录？
因为 fsnotify.Watcher 的设计是路径粒度的，不是递归模型。调用 watcher.Add("/a") 只注册了 /a 这个目录本身，不包含其子项——操作系统底层（如 Linux inotify）也默认不递归，需显式为每个子目录单独注册。
常见错误是直接监听根目录却期待子文件事件被触发，结果只有新建/删除 /a 本身时才收到事件，/a/b.txt 修改完全静默。
- 必须手动遍历目录树，对每个子目录调用
watcher.Add() - 推荐用
filepath.WalkDir（Go 1.16+）替代旧版filepath.Walk，它更安全、不 panic、支持按需中断 - 注意：添加子目录前先检查
info.IsDir()，避免对文件调用Add()导致panic: cannot watch file
如何避免监听启动时的“初始事件风暴”？
当调用 watcher.Add() 后，某些系统（尤其是 macOS FSEvents）会把目录下已有文件的 Create 事件批量推送过来，造成误触发。这不是 bug，而是底层机制决定的“快照式通知”。
解决办法不是过滤事件类型，而是引入初始化标记：
立即学习“go语言免费学习笔记（深入）”；
- 在
watcher.Add()完成后、开始读watcher.Events前，设一个isInitialized bool = false - 首次收到事件时，若
!isInitialized，仅记录日志或丢弃，然后置isInitialized = true - 后续所有事件才进入业务逻辑处理流程
- 不要依赖
event.Name是否为空或时间戳排序——不可靠
监听新创建的子目录时，如何自动加入监控？
fsnotify 不会自动监听动态新增的子目录，必须主动补注册。但直接在 Create 事件里调用 watcher.Add(newDir) 有竞态风险：目录可能刚建好但权限未就绪，或正被其他进程写入中。
稳妥做法是加一层延迟和校验：
- 收到
event.Has(fsnotify.Create)且info.IsDir()为 true 后，启动一个time.AfterFunc(100 * time.Millisecond, ...) - 回调中再用
os.Stat()确认目录存在且可读，再调用watcher.Add() - 失败时记录警告但不 panic，避免单个目录失败阻塞整个监听器
- 注意：Windows 下新建目录可能触发两次
Create（元数据 + 内容），需用filepath.Base(event.Name)去重判断
为什么热加载配置文件时总收到重复 Write 事件？
编辑器保存行为导致：VS Code、vim 等常采用“写临时文件 + 原子 rename”策略，一次保存可能触发 Create + Write + Remove 多个事件；有些编辑器还会额外写 backup 文件（如 .config.yaml~）。
关键不是合并事件，而是聚焦“最终状态”：
- 忽略
event.Name以~或.swp结尾的路径 - 对目标配置文件，只响应
event.Has(fsnotify.Write) && !strings.HasSuffix(event.Name, ".tmp") - 更健壮的做法是：收到
Write后，用os.ReadFile()读取当前内容，与上次缓存的 SHA256 对比，仅当哈希变化才 reload - 避免用
time.Sleep做 debounce——goroutine 阻塞会影响其他事件处理
真正的难点不在监听本身，而在区分“用户有意修改”和“编辑器副作用”。没做内容校验的热加载，大概率会在保存中途 reload 出错配置。
