fsnotify监听单个文件无效，必须监听父目录并用filepath.base(event.name)过滤；需同时处理write和rename事件以捕获编辑器原子写入，events通道须带缓冲并及时消费，递归监听需手动遍历注册。
直接监听单个文件路径（如 "config.yaml"）在 fsnotify 中基本无效，必须监听其父目录并手动过滤事件——这不是 bug，而是底层操作系统机制（inotify/kqueue/ReadDirectoryChangesW）的硬性限制。
为什么 watcher.Add("config.yaml") 总是没反应
因为 fsnotify 底层不接受纯文件路径。Linux 的 inotify、macOS 的 kqueue、Windows 的 ReadDirectoryChangesW 全部只支持监听目录句柄。传入文件路径时，watcher.Add() 在多数系统上会静默失败或返回 no such file or directory，但你没检查错误就继续了。
- 必须改用
watcher.Add(filepath.Dir("config.yaml"))，且确保该目录存在、有读权限（Linux/macOS 还需执行权限x） - 若路径含软链，先调
filepath.EvalSymlinks("config.yaml")解析真实路径，再取Dir，否则监听可能注册到符号链接自身而非目标目录 -
event.Name是相对路径（如"config.yaml"），不能直接和绝对路径比对；推荐用filepath.Base(event.Name) == "config.yaml"
如何可靠捕获编辑器保存后的最终内容
Vim、VS Code 等默认启用原子写入：新建临时文件（如 .config.yaml123456 或 config.yaml~）→ 写入 → Rename 覆盖原文件。此时原 inode 被销毁，仅监听 Write 会收到脏数据或完全无事件。
- 必须同时监听
fsnotify.Write和fsnotify.Rename，且优先响应后者——Rename才代表“覆盖完成” - 判断逻辑应为：
if event.Op&fsnotify.Rename != 0 && filepath.Base(event.Name) == "config.yaml" - 某些编辑器（如 macOS TextEdit）还会夹带
Chmod，别用字符串匹配event.String()，必须用位运算 - 收到事件后，立刻
os.Stat(event.Name)确认文件存在、非空，并跳过*~、.swp、.tmp等临时名
watcher.Events 为什么总丢事件
watcher.Events 是无缓冲 channel，内部 goroutine 向它发事件时，若无人消费就会阻塞，后续事件被丢弃甚至引发死锁。
- 必须用带缓冲的中转 channel，例如：
events := make(chan fsnotify.Event, 100) - 另起 goroutine 拉取
watcher.Events并转发到events，避免阻塞 watcher 内部逻辑 - 永远检查
event.Op的位掩码，不要写event.Op == fsnotify.Write——一个事件可能同时含Write | Chmod - 关闭 watcher 前，必须先停掉所有读
Events的 goroutine，否则会 panic：send on closed channel
递归监听子目录必须手动实现
watcher.Add("/a") 只监听 /a 目录自身的元数据变更（比如被重命名），对 /a/b/c.txt 的修改完全无感。fsnotify 没有 recursive: true 参数。
- 启动时全量注册：用
filepath.WalkDir(root, ...)遍历，对每个entry.IsDir()为 true 的路径调watcher.Add(path) - 运行时动态响应：监听到
fsnotify.Create且event.IsDir()为 true 时，立即watcher.Add(event.Name) - 加
sync.Mutex保护Add调用，避免多 goroutine 并发注册冲突 - 跳过符号链接：遍历时检查
entry.Type() & os.ModeSymlink != 0，否则可能触发权限错误或无限递归
最易被忽略的是：事件到达后不做 os.Stat() 二次确认，就直接读文件——这时可能读到正在被编辑器写入的中间状态，或已删除的临时文件。原子写入不是边缘情况，而是现代编辑器的默认行为。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
