fsnotify 为什么监听不到文件修改？
根本原因通常是监听路径没加对，或者事件类型没注册全。fsnotify 默认只监听 Write、Create、Remove、Rename 四类事件，但很多编辑器（如 VS Code、vim）保存时会先写临时文件再原子替换，触发的是 Remove + Create，而非直观的 Write。
- 确保用
watcher.Add("/path/to/dir")监听目录，而不是单个文件（文件被替换后原 fd 失效） - 显式注册所有关心的事件：
watcher.Add("./config"); watcher.Events = make(chan fsnotify.Event, 100)后，必须在 goroutine 中持续读取watcher.Events，否则缓冲区满会阻塞 - Linux 下注意 inotify 限制：默认单用户最多 8192 个 inotify 实例，可通过
/proc/sys/fs/inotify/max_user_watches调整
Go fsnotify 如何避免重复触发和漏事件？
重复触发常见于编辑器“保存即重写”行为；漏事件则多因通道缓冲不足或未及时消费。
- 对同一路径的连续
Write事件做简单去重：记录上一次事件的Event.Name和时间戳，间隔 - 通道缓冲大小至少设为 100：
make(chan fsnotify.Event, 100)，太小会导致事件丢失（fsnotify内部会丢弃） - 必须用独立 goroutine 消费事件：
go func() { for range watcher.Events { ... } }()，不能放在主流程里同步阻塞读 - 注意
fsnotify.Op是位掩码，判断是否为写操作应写成e.Op&fsnotify.Write != 0，而非e.Op == fsnotify.Write
监听符号链接时 fsnotify 行为不一致怎么办？
fsnotify 默认不跟随符号链接——它监听的是链接文件本身，不是目标路径。这常导致你以为在监控 /etc/config.yaml，实际只监控了 /etc/config.yaml 这个链接文件的元数据变化。
- 若需监控目标路径，先用
filepath.EvalSymlinks("/etc/config.yaml")解析真实路径，再对真实路径调用watcher.Add() - 如果链接目标是目录，且目标目录后续可能变动（比如滚动更新），建议监听父目录 + 过滤文件名，而非依赖链接解析结果
- Windows 下符号链接行为更复杂，
fsnotify可能完全无法触发目标变更事件，此时应改用轮询或考虑golang.org/x/exp/winfsnotify（非官方）
fsnotify 在容器环境或 NFS 挂载点下失效？
本质是底层 inotify 机制受限：容器中 /dev/inotify 可能未挂载或权限不足；NFS 不支持 inotify 事件透传，fsnotify 会静默失败（不报错，但无事件）。
立即学习“go语言免费学习笔记（深入）”；
- 容器内检查：
ls /dev/inotify，缺失则启动容器时加--device=/dev/inotify或改用hostPID: true共享宿主机 inotify - NFS 场景下，
fsnotify基本不可用，只能降级为定时os.Stat()检查ModTime()变化，间隔建议 ≥1s 避免 I/O 压力 - Docker Desktop（macOS/Windows）的文件共享层（gRPC-FUSE）也常丢事件，开发阶段建议把监听路径移到容器内部存储卷（如
/tmp），而非挂载的宿主机目录
Write，后者得靠 Create+Remove 组合判断，而且得在不同系统、不同存储后端上反复验证。 
