fsnotify 监控无反应主因是路径错误或权限不足；需用绝对路径监听目录、检查 inotify 限制、复用 watcher 实例、显式关闭、处理竞态与 rename 事件，并避免同步循环。
fsnotify 监控启动后没反应，event.Op 始终为空
常见于监听路径写错或权限不足。fsnotify 不会报错，而是静默跳过无效路径——比如传入相对路径但当前工作目录已变，或监听了文件而非目录（fsnotify 只能监听目录）。macOS 上还可能因 Spotlight 索引干扰导致首次事件延迟。
- 用
filepath.Abs()转绝对路径再监听，避免相对路径失效 - 确保监听的是目录，不是单个文件；如需监控某文件，监听其父目录 + 过滤
event.Name - Linux/macOS 下检查是否被
inotify限制：运行cat /proc/sys/fs/inotify/max_user_watches，太小（如默认 8192）就加到/etc/sysctl.conf - macOS 用户建议加
fsnotify.WithBufferSize(4096)防丢事件，尤其在大量小文件操作时
多个 fsnotify.Watcher 共存时 CPU 占用飙升
每个 Watcher 对应一个独立的 inotify 实例（Linux）或 FSEvents 流（macOS），频繁创建/关闭会触发内核资源重建，且未关闭的 Watcher 会持续占用句柄和内存。
- 全局复用一个
*fsnotify.Watcher，按需调用Add()/Remove()，别为每个子目录新建 Watcher - 务必在程序退出前调用
watcher.Close()；用defer容易漏掉（比如主 goroutine panic 后 defer 不执行），建议配合os.Interrupt信号显式关闭 - Windows 下注意：
fsnotify底层用 ReadDirectoryChangesW，对深层嵌套目录响应慢，建议限制监听深度或改用golang.org/x/exp/winfsnotify（非官方但更可控）
收到 fsnotify.Create 事件却读不到新文件内容
这是典型竞态：文件刚被 write() 就触发事件，但数据还没刷盘或写完。尤其在 rsync、git checkout 或编辑器保存（先写临时文件再 rename）场景下极常见。
- 不要一收到
Create就立即os.Open()；加简单重试逻辑，比如os.Stat()检查文件大小是否稳定、或等待time.Sleep(10 * time.Millisecond) - 重点处理
Rename事件：很多工具（如 VS Code、vim swap）用「写临时文件 + rename」方式保存，此时真正变更的是Rename而非Create - 避免用
event.Op&fsnotify.Write != 0判断修改——Write 事件在 macOS/Linux 上常被合并或抑制，rename 才是更可靠的“完成”信号
同步时如何避免循环触发（A 同步到 B → B 触发事件 → 又同步回 A）
双向同步最头疼的问题不是监听，而是事件来源不可信。fsnotify 不提供事件发起进程信息，只能靠路径、时间戳、临时标记等间接判断。
立即学习“go语言免费学习笔记（深入）”；
- 在目标目录写入同步标记文件（如
.syncing_<pid></pid>），同步前检查是否存在，存在则跳过本次事件 - 记录每次同步的
event.Name+event.Op+time.Now().UnixNano()到内存 map，10 秒内重复相同组合直接丢弃 - 更稳妥的做法：同步操作本身不走 fsnotify，而是用
os.Symlink()或os.Chmod()修改一个“控制文件”，让另一端只监听该控制文件变化来触发同步，切断事件链
实际做文件同步时，最麻烦的永远不是监听到事件，而是确认“这个事件该不该响应该由谁响应”。fsnotify 是个好耳朵，但它听不出谁在说话。
