fsnotify是Go生态中唯一可行的系统事件响应机制，因其基于内核原生事件、跨平台且低开销；watcher.Add()不报错也不生效常因路径不存在、权限不足或超出inotify限制，需先os.Stat校验并处理错误。
fsnotify 是唯一可行的系统事件响应机制，轮询或 syscall 封装都不可靠——它不是“可选方案”，而是 Go 生态里事实标准的、跨平台的、内核级事件桥接层。
为什么 watcher.Add() 突然不报错也不生效
常见现象是程序跑着跑着就收不到事件了，watcher.Events channel 完全静默。这不是 bug，而是 watcher.Add() 在路径不存在、权限不足或超出内核限制（如 Linux 的 /proc/sys/fs/inotify/max_user_watches）时**立刻返回 error**，但很多人直接忽略返回值。
- 必须在
watcher.Add(path)前先调os.Stat(path)，确认路径存在、是目录、且进程有读权限（os.FileMode & 0400 != 0） - 符号链接默认不跟随；要监听目标内容，得先用
filepath.EvalSymlinks()解析再 Add - 同一路径重复
Add()会 panic，不是“已存在”提示，需用map[string]bool缓存已注册路径 - Linux 下大量监听报
no space left on device？提前执行：echo 524288 > /proc/sys/fs/inotify/max_user_watches
如何安全递归监听整个目录树
fsnotify 默认只监听单层路径，所谓“递归监听”必须手动实现。但 filepath.WalkDir 不是万能解药——它扫描途中若目录被删或重命名，可能 panic 或漏加。
- 先
os.Stat(root)校验根路径存在且为目录，再开始遍历 - 在
WalkDirFunc中对每个fs.DirEntry判断IsDir()，仅对目录调watcher.Add() - 捕获
filepath.SkipDir错误跳过权限不足子目录，避免中断整个扫描 - 新创建的子目录不会自动被监听；需额外监听父目录的
fsnotify.Create事件，并动态Add() - 注意：容器环境要检查
/dev/inotify是否挂载，缺失则需启动参数加--device=/dev/inotify
watcher.Events 为什么突然开始丢事件
这不是网络抖动，而是 fsnotify 内部事件 channel 容量为 1，你传入的 watcher.Events 若无缓冲或缓冲太小，消费不及时就会静默丢弃新事件——不是阻塞，是直接丢。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 必须使用带缓冲 channel：
make(chan fsnotify.Event, 100)，高频率场景建议 500+ - 不能用
for range watcher.Events同步读取；必须起独立 goroutine 消费，且该 goroutine 不能含长耗时逻辑（如同步 HTTP 请求） - 过滤逻辑必须放在事件接收 goroutine 内部；若移到下游处理，未过滤事件会堆积在 channel 中，最终阻塞监听器
- macOS 上 FSEvents 不区分 Write 和 Chmod，统一返回
fsnotify.Chmod或空 Op；判断内容是否变更，必须补os.Stat(e.Name)对比ModTime()和Size()
关闭 watcher 时 goroutine 泄露的真实原因
watcher.Close() 不会清空已排队但未读取的事件，也不会等你读完 watcher.Errors；如果消费 goroutine 已退出，再往已关闭的 channel 发送残留事件，就会 panic：send on closed channel。
- 关闭前必须先用
context.WithCancel控制事件消费循环退出 -
Close()后要非阻塞读完两个 channel：select { case 和同理读 <code>watcher.Errors -
watcher不是线程安全的；多个 goroutine 同时调Add()或Remove()会出问题，需用sync.RWMutex封装保护 - 编辑器保存常触发原子写入（先写 tmp 再 rename），
Write事件不代表内容已落盘；稳妥做法是收到Write/Create/Rename后，启动time.AfterFunc(100 * time.Millisecond, ...)延迟读取
真正难的从来不是“怎么监听”，而是“怎么确保每次变更都被可靠捕获且不拖垮系统”——路径校验、缓冲大小、关闭顺序、事件去重，缺一不可。
