fsnotify.NewWatcher 创建失败主因是系统资源限制或权限问题：macOS 需调高 kern.maxfiles，Docker 需启用 inotify，Linux 需调整 ulimit 和 inotify 参数；Add 不递归，须手动遍历子目录添加；事件可能重复或丢失，建议业务层防抖；Close 后 events channel 立即关闭，需同步等待读取 goroutine 退出。
fsnotify.NewWatcher 创建失败怎么办
常见错误是 fsnotify.NewWatcher 返回 nil, error，尤其在 macOS 或 Docker 容器里。根本原因不是代码写错，而是系统资源限制或权限问题。
- macOS 上默认
kqueue事件数上限低，运行sysctl kern.maxfiles查看，若低于 10000，需临时调高：sudo sysctl -w kern.maxfiles=65536 - Docker 默认禁用 inotify，启动容器时加
--privileged或显式挂载/proc/sys/fs/inotify（不推荐生产） - Linux 下如果报
too many open files，检查ulimit -n，并在程序启动前用ulimit -n 65536调整
监听路径时为什么子目录没反应
fsnotify.Watcher.Add 只监听**单层路径**，不会递归。这是最常被误解的点——它不是“监控整个目录树”，而是“监控这个路径本身的元数据变化”。
- 想监听子目录，必须手动遍历并逐个
Add：用filepath.WalkDir遍历，对每个DirEntry调用watcher.Add - 注意跳过符号链接（
entry.Type()&os.ModeSymlink != 0），否则可能触发循环或权限错误 - 新增子目录不会自动加入监听，需在收到
fsnotify.Create事件后，判断是否为目录，再手动Add它
收到重复事件或漏事件怎么调
fsnotify 本身不保证事件去重，也不保证 100% 不丢——尤其在高并发文件操作（如 rsync、go build）场景下，底层 inotify/kqueue 有缓冲区溢出风险。
- Linux 下可调大内核参数：
echo 524288 | sudo tee /proc/sys/fs/inotify/max_queued_events - 业务层建议加简单防抖：对同一文件路径的
Write事件，用time.AfterFunc延迟 100ms 后统一处理，避免连续写入触发多次构建 - 不要依赖事件类型做精确状态判断（比如认为
Chmod一定表示权限改了），实际可能是编辑器临时文件写入导致的副作用
Watch.Close 后还能读 events channel 吗
不能。调用 watcher.Close() 会立即关闭 watcher.Events 和 watcher.Errors 两个 channel，后续从它们读取会立刻返回零值（非阻塞）。
立即学习“go语言免费学习笔记（深入）”；
- 务必在
Close前确保所有 goroutine 已退出对这两个 channel 的读取，否则可能 panic 或死锁 - 推荐模式：用
sync.WaitGroup管理监听 goroutine，在Close前调wg.Wait() - 如果监听逻辑封装成函数，别直接返回
watcher，而应返回一个带Stop() error方法的结构体，内部安全处理 channel 关闭和资源释放
