必须监听父目录并过滤事件：调用watcher.add(filepath.dir("file.log"))，在事件循环中用filepath.base(event.name)=="file.log"匹配，同时处理write、rename、remove事件，避免直接监听文件路径导致静默失败。
如何用 fsnotify 监控单个文件路径变更
直接监听文件而非目录是常见误区——fsnotify 本身不支持对普通文件的直接监控，必须监听其所在目录，再通过事件过滤判断目标文件是否被修改。否则你会收到 notify.ErrNonExistent 或静默失败。
实操要点：
- 调用
watcher.Add("/path/to/dir")，不是"/path/to/file.log" - 在
select循环中检查event.Name == "/path/to/file.log"，注意路径需完全匹配（建议用filepath.Base(event.Name)或filepath.Clean(event.Name)标准化） - 如果文件可能被移动或重写（如 logrotate），需同时关注
fsnotify.Write、fsnotify.Rename和fsnotify.Remove事件 - Linux 下 inotify 有句柄限制，默认 8192，大量监控时需调大
/proc/sys/fs/inotify/max_user_watches
上报逻辑必须带重试与背压控制
文件变更频率可能远高于上报通道吞吐能力，尤其日志轮转时短时爆发大量 Write 事件。不做节流会压垮 HTTP 服务或丢数据。
关键设计：
- 用带缓冲的 channel（如
make(chan string, 100)）暂存待上报路径，避免阻塞监听循环 - 上报 goroutine 应实现指数退避重试：首次失败后 sleep
100 * time.Millisecond，每次翻倍，上限设为30 * time.Second - HTTP 上报务必设
context.WithTimeout(ctx, 5*time.Second)，防止 hang 住整个 worker - 若上报失败且 buffer 满，可考虑丢弃旧事件（LRU）或记录本地 fallback 文件，而非 panic
Windows 下 rename 事件行为差异极大
Windows 的 fsnotify 后端基于 ReadDirectoryChangesW，对原子重命名（如 mv new.log old.log）常触发 Remove + Create，而非单个 Rename。这会导致你误判为文件删除重建，丢失上下文。
应对方式：
- 不要依赖单一事件类型做业务决策，改用「文件内容哈希比对」或「inode（Linux/macOS）/fileid（Windows）」识别同一文件实体
- Windows 上可调用
syscall.GetFileInformationByHandle获取FileIndexLow+FileIndexHigh作为稳定标识 - 测试时务必在目标平台验证，跨平台代码不能假设
event.Op&fsnotify.Rename != 0就代表重命名成功
避免长连接泄漏和 watcher 泄露
fsnotify.Watcher 是系统资源，未关闭会导致 inotify 句柄泄漏，进程运行越久越容易 hit too many open files 错误。Go 程序退出时必须显式 watcher.Close()。
安全做法：
- 把
watcher放进 struct 中，实现Close() error方法统一释放 - 使用
defer watcher.Close()仅适用于短期命令行工具；长期服务需配合os.Interrupt信号处理 - 若需动态增删监控路径，不要反复
NewWatcher()，复用同一实例并调用Add/Remove - Watch 目录下子目录新增时不会自动递归，要监听子目录必须显式
Add，无自动发现机制
真正麻烦的是路径权限变化和 NFS 挂载点抖动——这些场景下 fsnotify 可能静默停止投递事件，没有错误反馈。上线前得在真实部署环境跑够 24 小时以上观察。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
