fsnotify.Watcher启动后无反应，因Events通道无缓冲需立即用goroutine消费；监听子目录须手动递归；避免重复事件需时间窗口去重或ModTime稳定性检查；务必显式Remove路径再Close。
Go 标准库不支持原生文件系统事件监听，fsnotify 是事实标准，但直接用容易漏事件、卡死协程、误报重复事件。
为什么 fsnotify.Watcher 启动后没反应？
常见原因是没持续读取 watcher.Events 通道 —— 它是无缓冲通道，写满后系统事件会被丢弃。必须在启动后立即起 goroutine 消费：
watcher, _ := fsnotify.NewWatcher()
defer watcher.Close()
<p>go func() {
for {
select {
case event, ok := <-watcher.Events:
if !ok {
return
}
fmt.Printf("event: %v\n", event)
case err, ok := <-watcher.Errors:
if !ok {
return
}
log.Println("error:", err)
}
}
}()- 漏掉
go启动这个循环，watcher就会卡住或静默失败 -
watcher.Add("path")必须在 goroutine 启动之后调用，否则可能错过首次事件 - Windows 下对符号链接、网络驱动器支持弱，
fsnotify可能直接报operation not supported
fsnotify 监听子目录要手动递归吗？
是的。fsnotify 默认只监听指定路径的直接子项，不会自动递归。监听整个目录树需自己遍历：
func watchDirRecursive(watcher *fsnotify.Watcher, dir string) error {
filepath.Walk(dir, func(path string, info os.FileInfo, err error) error {
if err != nil {
return err
}
if info.IsDir() {
return watcher.Add(path)
}
return nil
})
return nil
}-
filepath.Walk可能因权限问题 panic，建议加defer/recover或提前检查info.Mode() & os.ModePerm - Linux 下 inotify 有单进程上限（
/proc/sys/fs/inotify/max_user_watches），递归太多目录会触发too many open files - macOS 的 kqueue 对深层嵌套目录响应延迟明显，建议限制递归深度
如何避免重复触发 WRITE 事件？
编辑器保存文件常触发多次 fsnotify.Write（如先 truncate 再 write），且 os.Rename 会拆成 Remove + Create。不能只靠事件类型判断变更完成：
立即学习“go语言免费学习笔记（深入）”；
- 对同一文件路径做时间窗口去重：记录最近一次事件时间，
time.Since(last) < 100 * time.Millisecond则忽略 - 真正可靠的方式是监听
Create+Write后，用os.Stat检查ModTime()是否稳定（连续两次相差 < 50ms） - 不要依赖
event.Name判断文件是否“已就绪”——临时文件（如file.txt~或.#file.txt）可能被误判
替换 fsnotify 的轻量方案有哪些？
如果只要轮询检测（比如容器内 or 文件系统不支持 inotify/kqueue），可用 github.com/fsnotify/fsnotify 的替代思路：
-
golang.org/x/exp/fs/walk（实验包）+ 定时os.Stat对比ModTime和Size，适合低频场景 -
github.com/radovskyb/watcher封装了fsnotify并内置防抖和递归，但依赖较重 - 生产环境若需高可靠性（如日志采集），建议直接对接
inotifywait（Linux）或fswatch（macOS）命令行工具，用exec.Command调用并解析 stdout
最易被忽略的是：所有监听逻辑必须在 watcher.Close() 前显式移除路径（watcher.Remove(path)），否则进程退出时资源未释放，下次启动可能因 inotify 句柄耗尽而失败。
