fsnotify漏事件是因底层inotify/kqueue/ReadDirectoryChangesW缓冲区溢出或atomic write导致路径失效；应监听目录而非文件，用filepath.Base过滤，并防抖处理多事件。
为什么 fsnotify 会漏掉文件事件
fsnotify 不是“监听文件”，而是监听内核的 inotify（Linux）、kqueue（macOS）或 ReadDirectoryChangesW（Windows）事件，底层有缓冲区和队列限制。一旦写入速度超过消费速度，事件就会被丢弃——这不是 bug，是设计使然。
-
fsnotify.Watcher的内部缓冲区默认很小（Linux 上通常为 8192 字节），大文件批量写入、IDE 保存时触发的临时文件 + 主文件 + 备份文件连发，极易溢出 - 某些操作不产生可监听事件：比如
os.Rename()在同一文件系统内本质是renameat2系统调用，只触发FS_MOVED_TO或FS_MOVED_FROM，但若重命名后立刻写入，旧路径已失效，新路径的FS_CREATE可能还没来得及注册监听 - 编辑器如 VS Code、Sublime 默认启用 atomic write：先写到
file.tmp，再rename覆盖原文件——你监听的是原路径，但rename后原路径已不存在，新文件其实是“新建”行为，需确保监听目录而非单个文件
如何正确监听整个目录并过滤目标文件
直接 w.Add("config.json") 是最常见错误；一旦文件被替换或重命名，监听就失效。必须监听父目录，再在事件回调里用 filepath.Base(event.Name) 或 filepath.Ext(event.Name) 过滤。
- 监听目录时，
event.Op对新建文件是fsnotify.Create，对修改是fsnotify.Write，但 macOS 上可能合并为fsnotify.Chmod（因 touch 更新 mtime） - 避免重复触发：一个保存动作常伴随
Create→Write→Chmod多个事件，建议用time.AfterFunc做简单防抖，或记录event.Name+event.Op的最近时间戳 - Windows 下注意路径分隔符：
event.Name返回的是\分隔的字符串，用filepath.Clean()统一处理，别用strings.Contains(event.Name, "/")
// 正确做法：监听目录，再判断
err := w.Add("configs/")
if err != nil {
log.Fatal(err)
}
go func() {
for {
select {
case event, ok := <-w.Events:
if !ok {
return
}
if filepath.Base(event.Name) == "app.yaml" && event.Has(fsnotify.Write) {
reloadConfig()
}
case err, ok := <-w.Errors:
if !ok {
return
}
log.Println("watch error:", err)
}
}
}()
fsnotify 在容器或 NFS 挂载目录中为何不工作
inotify 依赖 Linux 内核的 inotify 实例，而容器默认共享宿主机的 PID namespace 但隔离了 inotify fd；NFS 客户端不转发 inotify 事件到服务端，服务端也收不到客户端的变更通知。
- Docker 中需加
--privileged或显式配置--cap-add=SYS_INOTIFY_INIT（实际多数镜像仍不支持，推荐改用轮询 fallback） - Kubernetes Pod 若挂载 ConfigMap/Secret 卷，它们是 tmpfs，inotify 可用，但内容更新由 kubelet 触发，事件类型为
Chmod（因只改了 mtime），不是Write - 跨平台部署时，别假设
fsnotify总可用：用build tags隔离逻辑，Linux/macOS 用 fsnotify，Windows 容器或 NFS 环境降级为time.Ticker+os.Stat()检查ModTime()变化
如何安全关闭 fsnotify Watcher 并避免 panic
w.Close() 不是线程安全的，如果正在读 w.Events 通道时调用它，后续从该通道读取会 panic：panic: send on closed channel。必须确保 goroutine 已退出，或用 sync.Once + 标志位协调。
立即学习“go语言免费学习笔记（深入）”；
- 永远不要在多个 goroutine 中并发调用
w.Close() - 关闭前应先停止事件消费 goroutine：可通过
context.WithCancel控制循环，或向控制 channel 发送退出信号 -
w.Close()返回后，w.Events和w.Errors通道立即关闭，此时再读会得到零值（fsnotify.Event{}或nil错误），所以读循环必须检查ok状态 - 忘记关闭会导致文件描述符泄漏——每个
Watcher在 Linux 上占用至少 1 个 inotify fd，ulimit -n超限后整个进程监听失败
Write 是有效配置变更，哪次是编辑器临时写入。这时候事件顺序、路径有效性、时间戳精度，全得自己兜底。 
