fsnotify.newwatcher创建失败常见原因：linux因inotify实例数限制（默认128）导致too many open files，需defer w.close()；macos在icloud drive等加密卷报operation not permitted；windows不支持监听符号链接目标内容且路径需用filepath.join。
fsnotify.NewWatcher 创建失败的常见原因
直接调用 fsnotify.NewWatcher() 报错 too many open files 或 operation not permitted，大概率不是代码写错了，而是系统资源或权限卡住了。
- Linux 下默认 inotify 实例数限制是 128，
fsnotify每个Watcher占一个，频繁创建不 Close 就会快速耗尽 —— 记得用defer w.Close()，别只在成功路径关 - macOS 上如果监听目录在 iCloud Drive 或某些加密卷里，可能触发
operation not permitted；换成本地路径（如/tmp）先验证逻辑 - Windows 不支持监听符号链接目标内容，但能监听链接文件自身变动；如果误以为“链接指向的文件变了会通知”，实际不会
监听子目录变动必须显式递归注册
fsnotify 默认不递归，哪怕你 w.Add("/path")，它也只盯这个目录节点本身（比如重命名该目录），不会自动覆盖其下所有子项。
- 要监听整个树，得自己遍历：用
filepath.WalkDir扫描所有子目录，对每个os.DirFS节点都调一次w.Add() - 注意 Windows 路径分隔符问题：
w.Add("abc")在 Windows 下可能被解释为转义字符，统一用filepath.Join("a", "b", "c") - 新增子目录不会自动加入监听 —— 收到
fsnotify.Create事件后，如果是目录，得手动w.Add(新路径)，否则后续变动收不到
事件类型判断别只看 String()，优先比对 Op 字段
日志里打印 Event.String() 看起来方便，但容易误判。比如 Chmod 和 Write 在某些编辑器保存时会连发，而 String() 输出可能含糊（像 "WRITE|CHMOD"），实际你需要的是原子操作。
- 正确做法是位运算判断：
if event.Op&fsnotify.Write != 0，而不是strings.Contains(event.String(), "WRITE") -
fsnotify.Rename和fsnotify.Remove都可能伴随fsnotify.Chmod（尤其 macOS），如果业务只关心“文件内容是否真变了”，建议忽略纯属性变更 - 文本编辑器保存常触发两轮：先写临时文件（
Create+Write），再原子替换原文件（Rename）。若只处理Write，可能拿到脏临时文件；等Rename更稳妥
Watch 后阻塞读取事件必须用 goroutine
w.Events 是无缓冲 channel，没人读就会卡住整个 Watcher 内部 goroutine，后续事件积压、甚至导致系统 inotify 队列溢出丢事件。
立即学习“go语言免费学习笔记（深入）”；
- 必须起独立 goroutine 消费：
go func() { for e := range w.Events { /* 处理 */ } }() - 别在循环里做耗时操作（比如解析大文件、http 请求）—— 事件堆积会导致延迟飙升；简单做法是把
e发给另一个 worker channel 异步处理 -
w.Errors同样要读，否则错误会卡死 channel；哪怕只打日志，也得写go func() { for err := range w.Errors { log.Println(err) } }()
真正麻烦的不是监听本身，是事件语义和编辑器行为之间的错位。同一个“保存”动作，在 VS Code、vim、macOS Finder 下触发的事件组合完全不同，得按实际工具链去适配，不能靠文档猜。