fsnotify 是 Go 监控文件变化的事实标准，需手动递归监听子目录、启动事件循环、正确解析 Op 位掩码、防抖去重、跨平台兜底及及时关闭 watcher 避免资源泄漏。
用 fsnotify 监控文件变化是最直接的选择
Go 标准库不提供原生文件监听能力，fsnotify 是事实标准。它封装了各平台的底层机制（inotify/kqueue/ReadDirectoryChangesW），不用自己写 syscall。直接 go get github.com/fsnotify/fsnotify 即可使用。
常见错误是只监听目录却没递归处理子目录——fsnotify 默认不递归，必须手动遍历并为每个子目录调用 watcher.Add()；另一个坑是监听后忘记启动事件循环，导致 watcher.Events 通道阻塞或漏事件。
- 监听单个文件时，路径必须存在且有读权限，否则
Add()返回 error - 监听目录时，对目录本身有执行（x）权限才可能成功（Linux/macOS）
- Windows 下若文件被其他进程独占打开（如 Excel 编辑中），重命名或删除事件可能收不到
- 事件通道需另起 goroutine 消费，否则会卡住 watcher 内部逻辑
区分文件创建、修改、删除事件要靠 Event.Op 字段
fsnotify.Event 的 Op 是位掩码，不是单一值。不能用 == 判断，得用按位与：
if event.Op&fsnotify.Write == fsnotify.Write {
// 实际可能是 Write|Chmod，但至少发生了写入
}
典型误判场景：文本编辑器保存文件常触发 Write + Chmod，直接比对 event.Op == fsnotify.Write 会失败；又比如 Vim 的 swap 文件临时写入也会发 Write，但你可能只想响应真实内容变更。
立即学习“go语言免费学习笔记（深入）”；
-
Create和Write都可能对应“新建文件”，区别在于：空文件先Create后Write，而带内容的一次性创建（如cp）通常只触发Create -
Remove在 macOS 上对目录可能不触发，需配合Chmod（目录权限变 000）间接判断 - 重命名（mv）在大多数平台表现为
Remove+Create，但同一文件系统下也可能只有Rename事件（取决于内核版本和实现）
避免重复事件和性能抖动的关键是加缓冲和去重
编辑器保存、git checkout、IDE 索引等操作常在毫秒级连续触发多次 Write，直接逐条处理会导致逻辑错乱或 CPU 拉满。必须引入防抖（debounce）或合并（throttle）逻辑。
简单做法是用 time.AfterFunc 延迟执行，每次新事件到达就取消旧定时器；更稳妥的是用 channel + ticker 统一聚合事件，例如 100ms 窗口内收集所有变更路径，再批量处理。
- 不要在事件回调里做耗时操作（如解析 JSON、调用 HTTP），应转发到 worker pool
- 对同一路径的高频事件（如日志轮转），可用 map 记录上次处理时间戳，跳过间隔太短的重复项
- 监控大目录（如
node_modules）时，务必过滤掉不需要的扩展名，否则 inotify watch 数量可能超限（Linux 默认 8192）
跨平台兼容性差异必须手动兜底
fsnotify 虽统一接口，但行为差异明显：macOS 的 kqueue 对符号链接目标变更不敏感；Windows 的 ReadDirectoryChangesW 不报告子目录的 Create，只报目录自身变更；Linux inotify 不监听文件内容修改，只监听 inode 级事件（所以硬链接改内容不会触发）。
真正健壮的工具往往要组合策略：对关键文件（如配置文件）额外用 os.Stat() 对比 ModTime() 和 Size() 做兜底轮询（间隔 1–5 秒），尤其当监听失败或平台限制导致事件丢失时。
- 用
runtime.GOOS区分平台逻辑，比如 Windows 下需额外处理长路径（\\?\C:\...） - 某些容器环境（如 Docker Desktop for Mac）的文件共享机制会导致 inotify 事件延迟或丢失，此时轮询是唯一可靠方式
- 不要依赖
Event.Name的绝对路径——它只是相对监听路径的相对名，拼接时要用filepath.Join()，且注意结尾斜杠一致性
watcher.Close() 会导致 inotify fd 泄漏，最终进程被系统 kill。哪怕只是 CLI 工具，也要用 defer watcher.Close() 或 signal.Notify() 捕获 os.Interrupt 做清理。 
