必须用 fsnotify，因其避免了 syscall.Inotify 的 fd 泄漏、平台限制和非递归问题，以及轮询 os.Stat 导致的事件丢失、CPU 占高和符号链接失效；watcher.Add 在路径不存在、权限不足或超出内核 inotify 限制时立即返回 error，而非延迟报错或写入 Errors channel；监听前需 os.Stat 校验路径存在与读权限，符号链接需显式解析；Linux 大量监听需提升 max_user_watches；Events 和 Errors 须用 select 配 default 分支安全读取，避免阻塞；业务逻辑需去重处理连续事件；关闭 watcher 前应先停止消费逻辑，再 Close() 并非阻塞读尽残留事件与错误；递归监听需手动 WalkDir 实现；跨平台事件差异大，需结合 ModTime/Size 判断内容变更，并过滤临时文件；路径比对统一用 filepath.Abs。
必须用 fsnotify，别自己封装 syscall.Inotify*，也别轮询 os.Stat —— 前者 fd 泄漏、平台不可用、不递归；后者丢事件、CPU 拉满、对重命名和符号链接完全无感。
为什么 watcher.Add 静默失败或 panic
watcher.Add 在路径不存在、权限不足、超出内核限制（如 Linux 的 /proc/sys/fs/inotify/max_user_watches）时，**立刻返回 error**，不是延迟报错，也不是写进 watcher.Errors channel。很多人直接写 watcher.Add(path) 忽略返回值，结果后续从 watcher.Events 读 channel 时卡死或 panic。
- 监听前务必先调
os.Stat(path)，确认路径存在且有读权限（目录需可readdir，即os.FileMode & 0400 != 0） - 符号链接默认不跟随；若要监听目标内容，得先
filepath.EvalSymlinks解析再Add - Linux 上大批量监听报
no space left on device，需提前提升限制：echo 524288 > /proc/sys/fs/inotify/max_user_watches
如何安全读取 watcher.Events 和 watcher.Errors
这两个 channel 都是无缓冲的，没人读就会阻塞整个 watcher —— 尤其 watcher.Errors，一旦写入错误没人消费，后续所有事件都发不出。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 必须用
select同时监听两个 channel，且至少一个分支带default防止死锁 - 不要在
for range watcher.Events里直接处理业务逻辑；编辑器保存常触发连续Create+Write，建议加去重（例如 100ms 内同名Write合并） - 关闭 watcher 前，先停掉你的事件消费逻辑（比如用
context.WithCancel控制主循环），再调watcher.Close() -
Close()后，channel 仍可能残留最多 1 个事件和 1 个错误，需非阻塞读完，否则可能panic: send on closed channel
递归监听与跨平台事件处理的坑
fsnotify 默认不递归，也不统一报告事件细节：macOS 的 FSEvents 不区分 Write 和 Chmod，Windows 对符号链接支持弱，编辑器原子写入（先写 tmp 再 rename）在各平台表现不一致。
立即学习“go语言免费学习笔记（深入）”；
- 递归监听必须手动实现：
filepath.WalkDir遍历，对每个os.DirEntry调watcher.Add（跳过 symlink 除非明确需要） - 判断文件内容是否变更，不能只信
event.Op & fsnotify.Write；应结合os.Stat比较ModTime()和Size() - 过滤临时文件：
Event.Name做后缀检查（如.*~、.*.swp、.DS_Store），而非字符串前缀匹配 - 路径比对务必用
filepath.Abs统一格式，避免因相对路径、..或大小写导致误判
真正难的不是启动监听，而是让 watcher 在进程生命周期内稳定跑完——从路径校验、递归添加、事件去重、错误消费，到最终安全关闭，每一步漏掉都可能引发 goroutine 泄漏、fd 耗尽或事件丢失。尤其在容器环境或长期运行服务中，这些点容易被忽略，但出问题时往往没有明显报错，只有“监控突然不灵了”。
