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）场景下极常见。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• 不要一收到 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 不提供事件发起进程信息，只能靠路径、时间戳、临时标记等间接判断。

• 在目标目录写入同步标记文件（如 .syncing_），同步前检查是否存在，存在则跳过本次事件
• 记录每次同步的 event.Name + event.Op + time.Now().UnixNano() 到内存 map，10 秒内重复相同组合直接丢弃
• 更稳妥的做法：同步操作本身不走 fsnotify，而是用 os.Symlink() 或 os.Chmod() 修改一个“控制文件”，让另一端只监听该控制文件变化来触发同步，切断事件链

实际做文件同步时，最麻烦的永远不是监听到事件，而是确认“这个事件该不该响应该由谁响应”。fsnotify 是个好耳朵，但它听不出谁在说话。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！