fsnotify不能直接监听单个文件，必须监听父目录并过滤event.Name；需同时处理Write和Rename事件（优先响应后者）以捕获编辑器原子写入；递归监听须手动遍历注册子目录，Events通道必须带缓冲且及时消费，否则丢事件。
fsnotify 不能直接监听“目录内容变更”——它监听的是**目录节点自身的事件**，比如子项增删、重命名；你真正想捕获的“某个配置文件被保存”，必须靠监听父目录 + 过滤事件 + 处理原子写入。不这么做，watcher.Add("config.yaml") 在 Linux/macOS 下静默失败，Windows 下可能 panic。
为什么 watcher.Add("file.txt") 总是没反应
因为操作系统（inotify/kqueue/ReadDirectoryChangesW）根本不支持监听单个文件路径。传入文件路径时，fsnotify 尝试注册该路径的 inode 或句柄，但文件没有目录项可监听，结果是：no such file or directory 或 invalid argument，且不报错。
- 必须改用
watcher.Add(filepath.Dir("file.txt"))，监听其父目录 - 若路径含软链，先调
filepath.EvalSymlinks()解析真实路径再取Dir，否则监听注册到符号链接自身而非目标目录 -
event.Name是相对路径（如"config.yaml"），过滤时用filepath.Base(event.Name) == "config.yaml"，别用字符串匹配全路径
如何可靠捕获编辑器保存后的最终内容
Vim、VS Code 等默认启用原子写入：先写临时文件（如 .config.yaml.swp 或 config.yaml~），再 rename 覆盖原文件。只监听 Write 会拿到脏临时文件，或完全收不到事件。
- 必须同时关注
fsnotify.Write和fsnotify.Rename，且优先响应后者——Rename才代表“保存完成” - 判断用位运算：
if event.Op&fsnotify.Rename != 0，别用strings.Contains(event.String(), "RENAME")，不可靠 - 收到事件后立刻
os.Stat(event.Name)，确认文件存在、非空、且后缀不是~、.swp、.tmp
怎样监听整个子树并动态响应新增目录
watcher.Add("/a") 只监听 /a 目录自身的元数据变更（比如被重命名），对 /a/b/c.txt 的修改完全无感。没有 recursive: true 这种参数。
- 启动时全量注册：用
filepath.WalkDir(root, ...)遍历，对每个entry.IsDir()为true的路径调watcher.Add(path) - 运行时动态响应：监听到
fsnotify.Create且event.IsDir()为true时，立即watcher.Add(event.Name) - 加
sync.Mutex保护Add调用，避免多 goroutine 并发注册冲突 - 跳过符号链接：
if entry.Type()&os.ModeSymlink != 0，否则可能触发权限错误或无限递归
Events channel 不消费就会丢事件
w.Events 是无缓冲 channel，没人读就会卡住整个 Watcher 内部 goroutine，后续事件积压，甚至导致系统 inotify 队列溢出丢事件。
立即学习“go语言免费学习笔记（深入）”；
- 必须起独立 goroutine 消费：
go func() { for range w.Events { ... } }() - channel 必须带缓冲（例如
make(chan fsnotify.Event, 1024)），否则高并发写入下极易丢事件 -
w.Close()后Eventschannel 立即关闭，需同步等待读取 goroutine 退出，否则可能 panic - 底层 inotify 缓冲区默认很小（Linux 通常 8192 字节），大文件批量写入或 IDE 保存连发临时+主+备份文件，极易溢出
Rename，而监听失效往往是因为误传文件路径、没做 EvalSymlinks、或新增子目录后没手动 Add。这些点不补上，fsnotify 就只是个半成品监听器。 
