fsnotify 监听目录而非文件，编辑器重写导致 remove+create 事件被忽略；应监听目录并白名单过滤文件名，同时响应 opwrite 和 opchmod，调大 inotify 限制，热重载需原子替换配置并校验错误，windows 下需捕获 error_operation_aborted 并重建 watcher，日志轮转应避免使用 fsnotify。
为什么 fsnotify 的 Watch 会漏掉文件修改？
fsnotify 不是“监听文件”，而是监听目录——这是绝大多数漏事件的根本原因。你 watch.Add("config.yaml") 看似在监听文件，实际底层注册的是该文件所在目录的 inotify watch，再靠用户态过滤事件。一旦文件被编辑器重写（如 vim、vscode 默认行为），旧文件被删、新文件被新建，fsnotify 就收不到 WRITE，只收到 REMOVE + CREATE，而你若没监听 OpCreate，就以为“没变”。
- 始终用
watch.Add("path/to/dir")，而不是单个文件路径 - 对关注的文件名做白名单过滤：检查
event.Name是否匹配目标文件，而非依赖路径直传 - 编辑器保存时触发
Chmod或Write未必稳定，OpWrite可能只发一次（大文件分块写）或不发（仅改 mtime），建议同时响应OpChmod - Linux 下 inotify 有 fd 限制，默认 8192，大量目录监听易触发
too many open files，需调大/proc/sys/fs/inotify/max_user_watches
如何安全地 reload 配置而不中断服务？
收到 fsnotify.Event 后直接 json.Unmarshal 到全局变量，是典型竞态源。热重载必须满足两个条件：原子性、可回退。否则可能一半配置已更新，另一半仍读旧值，或解析失败导致 panic。
- 永远用新结构体实例解析：不要
json.Unmarshal(data, &cfg)，而是var newCfg Config; json.Unmarshal(data, &newCfg) - 校验通过后再原子替换：用
sync/atomic.Value存储指针，或用sync.RWMutex保护读写，写时加写锁，读时只加读锁 - 务必捕获
json.Unmarshal错误，失败时保留旧配置并 log，绝不能 panic 或静默丢弃 - 避免在 handler 中做耗时操作（如 HTTP 请求、DB 连接测试），这些应放在 reload 完成后异步触发
Windows 下 fsnotify 报 ERROR_OPERATION_ABORTED 怎么办？
这是 Windows 特有的 I/O 取消错误，常见于进程退出、goroutine 被 cancel、或监听路径被系统临时锁定（如杀毒软件扫描）。它不是 bug，但默认会被 fsnotify 转为 panic 或静默关闭 watcher。
- 启动 watcher 后，必须显式启动一个 goroutine 持续读取
watch.Events和watch.Errors通道，否则 error 会阻塞 - 遇到
ERROR_OPERATION_ABORTED（表现为errors.Is(err, syscall.ERROR_OPERATION_ABORTED)）应重建 watcher：先watch.Close()，再new(fsnotify.Watcher)，重新Add路径 - Windows 对符号链接支持弱，若路径含 symlink，优先用绝对路径 resolve 后再监听，避免
no such file or directory - 避免监听网络驱动器（如
Z:\）或 OneDrive 同步目录，其事件延迟高、丢失率高，建议只监本地 NTFS 卷
要不要用 fsnotify 监控日志轮转？
不要。logrotate、rsyslog 等工具轮转日志时，典型行为是 rename + create，fsnotify 会看到原文件 RENAME（或 REMOVE）和新文件 CREATE，但你的程序通常只关心“当前日志内容追加”，而不是文件名变化。轮转后继续写入的是新文件，旧 watcher 依然挂在老路径上，自然收不到新事件。
立即学习“go语言免费学习笔记（深入）”；
- 监控日志内容追加，请用
tail -f类逻辑：打开文件、seek 到 EOF、循环 read；或用现成库如github.com/hpcloud/tail - 若真要用 fsnotify 做轮转感知，必须监听父目录，并对
OpCreate事件检查文件名是否匹配轮转模式（如app.log.1,app.log.2024-04-01），再决定是否切换 reader - 注意：轮转期间可能有写入间隙，
CREATE事件到达时文件可能为空，需等待首次WRITE或主动 sleep+stat 轮询确认非空
最麻烦的从来不是监听本身，而是事件语义和业务意图之间的 gap——比如你以为“文件变了就得 reload”，但实际可能是编辑器临时文件、IDE 自动保存、或者 NFS 缓存延迟。盯住 event.Op 和 event.Name，比盯住文档更管用。
