fsnotify 为什么监听不到文件修改？
根本原因通常是监听路径没权限，或监听的是符号链接指向的原始路径而非链接本身。macOS 上还容易因 Spotlight 索引干扰导致事件丢失。
-
fsnotify默认不递归监听子目录，watch.Add("dir")只监听"dir"目录自身（比如重命名、删除该目录），不监听其内部文件变化 - 要监听子目录，必须手动遍历 + 对每个子目录调用
watch.Add()；或者改用fsnotify.NewWatcher()后配合filepath.WalkDir实现递归注册 - Linux 下如果被监听目录在 NFS 或某些容器挂载卷中，
inotify机制可能失效，此时fsnotify会静默降级为轮询（性能暴跌且默认关闭） - 常见错误现象：
WRITE事件没触发，但实际文件已保存——可能是编辑器先写临时文件再原子替换（触发的是CREATE+REMOVE，不是WRITE）
如何正确处理 fsnotify.Events 中的多个事件类型？
一个文件保存动作常触发多个事件，比如 VS Code 保存会先 CREATE 临时文件、再 REMOVE 原文件、最后 RENAME 临时文件为原名。直接按 event.Op&fsnotify.Write 判断容易误判。
- 优先检查
event.Op & fsnotify.Chmod != 0—— 权限变更通常无关业务逻辑，可忽略 - 对
fsnotify.Create和fsnotify.Write都要响应，但需加去重：用time.Now()记录最近一次事件时间，100ms 内同路径重复事件丢弃 - 注意
event.Name是相对路径（如"config.json"），不是绝对路径；若监听的是"./data"，事件里event.Name可能是"data/cache.bin"，需拼接才能得到完整路径 - Windows 下
fsnotify.Rename事件可能拆成两个独立事件（旧名删除 + 新名创建），不能假设一定成对出现
资源泄漏：为什么程序跑一会儿就报 too many open files？
每调用一次 watch.Add()，fsnotify 就在内核申请一个 inotify 实例（Linux）或 FSEvents 流（macOS）。不显式关闭，进程退出前不会释放。
- 务必在程序退出前调用
watch.Close()；用defer watch.Close()不够——它只在函数返回时执行，而监听通常是长运行 goroutine - 如果动态增删监听路径（比如用户配置变更），旧路径要先
watch.Remove(oldPath)，否则残留 inotify 实例持续占用 fd - Linux 默认单进程 inotify 实例上限是 128，可通过
cat /proc/sys/fs/inotify/max_user_watches查看；超限后watch.Add()返回no space left on device错误，不是 panic - 避免监听整个
$HOME或/tmp这类高变动目录——事件风暴会导致 goroutine 积压、CPU 暴涨
跨平台行为差异：macOS 和 Windows 下要注意什么？
fsnotify 在不同系统底层机制完全不同：Linux 用 inotify，macOS 用 FSEvents，Windows 用 ReadDirectoryChangesW。这意味着事件粒度、延迟、甚至触发条件都不同。
立即学习“go语言免费学习笔记（深入）”；
- macOS 上
fsnotify.Chmod几乎从不触发（FSEvents 不上报权限变更），别依赖它做配置重载判断 - Windows 下短时间高频写入（如日志滚动）可能合并成单个
WRITE事件，且event.Name可能为空字符串，需用event.String()辅助调试 - 所有平台都不保证事件顺序：
CREATE未必在WRITE前，尤其涉及编辑器临时文件时 - 测试时别只跑 Linux Docker 容器——macOS 用户反馈“不工作”大概率是 FSEvents 的静默失败（比如监听路径含中文，FSEvents 要求 UTF-8 NFD 归一化）
最麻烦的其实是路径归一化和事件去重逻辑，不同编辑器、不同操作系统、不同文件系统写法全不一样，没有银弹。盯住 event.Name 和 event.Op 组合，再加一层基于 mtime 的兜底校验，比纯事件驱动更稳。
