macOS 上 fsnotify 经常漏触发 WRITE 事件，因其底层 FSEvents API 会合并小写入且不保证每次 write() 都生成独立事件；实操需同时监听 WRITE/CHMOD/ATTRIB，启用延时 stat 校验 ModTime 稳定性，并避免依赖单次 WRITE 判断保存完成。
为什么 fsnotify 在 macOS 上经常漏触发 WRITE 事件？
因为 macOS 的 FSEvents API 本身会合并多次小写入，且不保证每个 write() 都生成独立事件；fsnotify 只是封装层，无法绕过底层限制。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 监听
WRITE时，必须同时监听CHMOD和ATTRIB—— 许多编辑器（如 VS Code、vim）保存文件时先写临时文件再rename+chmod，漏掉后者就收不到信号 - 对关键路径启用
watcher.Add(path)后，立刻用filepath.WalkDir扫描当前状态，避免启动时已有文件被忽略 - 不要依赖单次
WRITE判断文件“已保存”——改为监听WRITE+ 短延时（如 100ms）后再次stat检查ModTime是否稳定
如何避免 fsnotify 监听器在子目录递归时崩溃？
fsnotify 默认不递归，手动遍历添加路径时，若遇到权限拒绝或符号链接循环，watcher.Add() 会 panic。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
filepath.WalkDir替代filepath.Walk，它支持返回fs.SkipDir控制跳过 - 在 walk 函数中捕获
os.IsPermission(err)并跳过，而非让Add()直接失败 - 对符号链接做深度限制（例如记录已访问的
inode），防止无限循环；可用os.Stat+os.FileInfo.Sys().(*syscall.Stat_t).Ino提取 inode - 每次
Add()前检查路径是否为目录（fi.IsDir()），避免对普通文件调用导致EINVAL
怎样让自动化脚本真正“可靠”地响应文件变更？
文件系统事件只是信号，不是操作完成确认。编辑器保存、git checkout、IDE 重构都可能分多步修改多个文件，顺序和原子性不可控。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 对同一路径的连续事件做去重合并：用
time.AfterFunc实现 debounce，比如 300ms 内只处理最后一次WRITE - 关键动作前加校验：比如监听
.go文件变化后，先运行go list -f '{{.Name}}' <file>确认语法合法，再执行构建 - 避免在事件回调里直接调用阻塞操作（如
exec.Command().Run()）——用goroutine+chan转发到工作池，防止事件队列堆积 - 记录最近一次成功处理的
ModTime和Size，下次收到事件时先比对，跳过未实际变更的“假触发”
Linux 下 inotify 限制导致 too many open files 怎么办？
fsnotify 在 Linux 底层用 inotify，每个 watched path 占一个 inotify instance，而默认 per-process 限制通常只有 8192。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
cat /proc/sys/fs/inotify/max_user_watches查当前上限；临时提高用sudo sysctl fs.inotify.max_user_watches=524288 - 监听根目录（如
/src）比逐个子目录更省资源，但需在事件回调里用strings.HasPrefix(event.Name, "sub/dir/")过滤路径 - 动态管理 watcher：不活跃的子目录（如 5 分钟无事件）可调用
watcher.Remove(path)，需要时再加回 - 注意 Docker 容器内该值常被设得很低，必须在
docker run时加--sysctl fs.inotify.max_user_watches=...
真正麻烦的不是监听本身，而是事件语义模糊——CREATE 可能是新建空文件，也可能是 mv 移入；WRITE 不代表内容最终态。得靠业务逻辑兜底，而不是指望文件系统给你准确答案。
