fsnotify优于轮询因其基于系统原生事件、零延迟且资源占用低，但需手动递归监听、避免重复add、处理长路径、过滤事件、缓冲channel、双监听补偿重启丢失、应对nas/符号链接/权限等边缘场景。
为什么用 fsnotify 而不是轮询
直接结论：轮询在高并发、大目录场景下 CPU 和 I/O 开销不可控，fsnotify 基于操作系统原生事件（Linux inotify / macOS FSEvents / Windows ReadDirectoryChangesW），零延迟、低资源占用。但要注意：它不递归监听子目录，也不保证事件顺序绝对严格（尤其大量快速写入时）。
常见错误是以为 fsnotify.Watcher.Add() 会自动递归——它只监听单层目录。需要手动遍历子目录并逐个 Add()，或借助 golang.org/x/exp/fs/walk（非标准库）辅助。
实操建议：
- 监听前先检查路径是否存在且可读：
os.Stat(path)，避免fsnotify报no such file or directory - 对同一路径重复
Add()会 panic，需自行去重或用map[string]bool缓存已监听路径 - Windows 下长路径（>260 字符）可能触发
ERROR_INVALID_PARAMETER，建议启用\?前缀或提前截断路径
fsnotify 的事件过滤和性能取舍
默认情况下，fsnotify 会把所有事件（Write、Create、Remove、Rename、Chmod）都发到 channel，但多数服务只关心 Create 和 Write。不做过滤会导致 goroutine 频繁唤醒、channel 积压、甚至丢事件（buffer 满后新事件被丢弃）。
关键点在于：fsnotify 的 event channel 是无缓冲的，默认容量为 1，必须及时消费，否则后续事件阻塞系统调用。
实操建议：
- 用带缓冲 channel：
make(chan fsnotify.Event, 1024)，但缓冲区不宜过大（>4096 易内存浪费） - 在 select 中加
default分支防阻塞，或用for range+time.AfterFunc控制处理节奏 - 过滤掉不需要的事件类型：
if event.Op&fsnotify.Write == 0 { continue }，比字符串匹配event.String()快一个数量级 - 注意
Rename事件常伴随Remove+Create，若业务依赖文件名唯一性，需合并判断
如何安全重启监听而不丢失事件
服务升级或配置变更时，需要替换 fsnotify.Watcher 实例。但旧 watcher 关闭瞬间，新 watcher 尚未就绪，中间窗口期的文件变更会丢失。这不是 bug，是设计使然——fsnotify 不提供事件回溯能力。
绕过方法不是“等旧 watcher 彻底退出再启新 watcher”，而是“双监听+时间窗口补偿”：
实操建议：
- 启动新 watcher 后，立即对目标路径做一次
filepath.Walk，对比上次快照（如文件 modtime + size），识别出新增/修改文件，人工触发一次Create/Write事件 - 旧 watcher 关闭前，记录最后收到事件的
event.Time（需自己 patch 或用runtime.nanotime()打标），新 watcher 启动后跳过早于该时间的事件（仅限支持纳秒精度的 OS） - 避免在
watcher.Close()后立刻os.RemoveAll()目录——某些 OS（如 macOS）会因句柄残留报device busy
生产环境必须处理的几个边缘 case
fsnotify 在容器、NAS、符号链接、权限变更等场景下行为差异大，很多问题只在线上突发。
实操建议：
- 挂载 NFS 或 CIFS 时，
fsnotify可能完全不工作（inotify 不支持网络文件系统），需 fallback 到定时 stat + hash 对比，用github.com/hpcloud/tail类库封装逻辑 - 符号链接目标变更后，原监听路径仍有效，但事件中的
Name是链接名而非真实路径，需用filepath.EvalSymlinks(event.Name)解析 - Linux 上 inotify instance 有上限（
/proc/sys/fs/inotify/max_user_instances），容器中默认值常为 128，超限报too many open files，需提前ulimit -n或共享 watcher 实例 - 临时文件（如编辑器生成的
.swp、~结尾）常触发大量噪声事件，建议在事件处理前用strings.HasSuffix(event.Name, "~")过滤
真正难的不是监听本身，而是怎么定义“文件变更”对业务有意义——比如日志轮转时 rename 旧文件、创建新文件，是否算作“新日志产生”？这得由业务逻辑决定，fsnotify 只负责把系统通知递过来。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
