fsnotify 是 Go 跨平台文件监控的唯一可行选择，它最小抽象各系统原生机制（Linux inotify、macOS kqueue、Windows ReadDirectoryChangesW），需监听目录而非文件、处理原子写入、递归注册及资源管理。
fsnotify 是 Go 跨平台文件监控的唯一可行选择，没有替代方案。标准库不提供类似能力，所有轮询（os.Stat + 定时器）或自己封装 syscall 的做法，都会在延迟、资源占用、事件丢失或平台兼容性上出问题。
为什么 fsnotify 是跨平台事实标准
它不是“封装得比较好”的第三方库，而是对操作系统原生机制的最小抽象：
- Linux 下调用
inotify，监听效率高、无 polling 开销 - macOS / BSD 用
kqueue，支持符号链接目标追踪（但默认不启用） - Windows 使用
ReadDirectoryChangesW，能响应长路径（需系统开启策略） - illumos 等小众系统也支持，靠
FEN后端
这意味着你写一次逻辑，编译到不同平台就能用——但行为差异必须主动适配，不能假设“表现一致”。
监听目录而非文件是硬性前提
watcher.Add("config.yaml") 在大多数平台会静默失败或 panic。fsnotify 底层不支持监听纯文件路径，必须监听其父目录：
立即学习“go语言免费学习笔记（深入）”；
- 用
filepath.Dir("config.yaml")获取目录路径再Add() - 收到事件后，用
filepath.Base(event.Name)匹配目标文件名，别直接字符串比较全路径 - 若路径含软链，先
filepath.EvalSymlinks()解析真实路径，否则可能监听到符号链接自身
否则 macOS 上改了目标文件没反应，Windows 下报 invalid argument，Linux 下返回 no such file or directory 却不报错。
原子写入导致监听失效的典型场景
Vim、VS Code、nano 等编辑器保存时默认用“临时文件 + rename”方式，原文件 inode 被丢弃，只监听 fsnotify.Write 会漏事件或捕获到临时文件（如 .config.yaml.swp）：
- 必须同时监听
fsnotify.Write和fsnotify.Rename，且优先响应后者 - 判断逻辑写成：
if event.Op&fsnotify.Rename != 0 && filepath.Base(event.Name) == "config.yaml" - 收到事件后立刻
os.Stat(event.Name)，确认文件存在、大小非零、后缀非~/.swp/.tmp - 某些编辑器（如 TextEdit）还会夹带
fsnotify.Chmod，别用strings.Contains(event.String(), "RENAME")这种不可靠方式判断
递归监听和资源管理是高频翻车点
fsnotify 默认不递归，watcher.Add("conf/") 只监听该目录自身的元数据变更（比如被 mv 或 chmod），对 conf/db.yml 的修改完全无感：
- 启动时递归注册：用
filepath.WalkDir("conf/", ...)遍历，对每个entry.IsDir()为 true 的路径调watcher.Add(path) - 运行时新增子目录：监听到
fsnotify.Create且event.IsDir()为 true 时，立即watcher.Add(event.Name)，加sync.Mutex防并发注册 panic -
watcher.Close()必须执行，否则 fd 泄漏；defer 放在NewWatcher()后是最简保障 -
watcher.Events是无缓冲 channel，必须用带缓冲的中转 channel（如make(chan fsnotify.Event, 100)）并另起 goroutine 拉取，否则事件堆积会阻塞内部 goroutine 导致死锁
真正难的不是“怎么写”，而是 macOS 上 kqueue 对深层嵌套目录（>100 层）可能触发 fsnotify.ErrEventOverflow，Windows 对长路径支持依赖系统策略，Linux 的 /proc/sys/fs/inotify/max_user_watches 太小会导致 Add() 返回 no space left on device —— 这些错误都不带明确提示，得靠日志和系统排查定位。
