fsnotify监听不到文件修改主因是编辑器原子写入导致inode变更；应监听目录、用缓冲channel处理事件、跨平台注意机制差异、及时Close避免资源泄漏。
fsnotify 为什么监听不到文件修改
常见现象是调用 watcher.Add() 后，改了文件却没收到 fsnotify.Write 事件。根本原因不是代码写错，而是 fsnotify 监听的是「文件路径」而非「文件内容」——如果编辑器保存时用了“原子写入”（如 vim、vscode 默认行为），实际是新建临时文件 + rename 覆盖原文件，原 inode 被丢弃，监听就断了。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 监听目录而非单个文件，因为
rename会触发fsnotify.Rename事件，可据此捕获“被覆盖”的文件 - 对关键配置文件，可搭配
fsnotify.Chmod（某些编辑器会先改权限）和fsnotify.Write一起判断 - Linux 下注意 inotify 限制：
/proc/sys/fs/inotify/max_user_watches太小会导致添加失败且无明确报错，watcher.Add()返回no space left on device
如何正确处理 fsnotify 的 Event 事件流
很多人直接在 watcher.Events channel 上 range，结果漏事件或 panic。这不是 channel 使用习惯问题，而是 fsnotify 的设计：Events 是非缓冲 channel，发送速度 > 接收速度时会阻塞 watcher 内部 goroutine，最终导致后续事件丢失甚至死锁。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 必须用带缓冲的 channel 中转，例如
events := make(chan fsnotify.Event, 100)，再另起 goroutine 拉取watcher.Events并转发 - 永远检查
event.Op而非只看event.Name，因为同一事件可能含多个操作位（如fsnotify.Write | fsnotify.Chmod） - Windows 下
fsnotify.Create可能触发两次（先建文件，再写内容），需用time.Sleep(10 * time.Millisecond)去抖动，或改用文件大小/修改时间二次确认
跨平台监听的坑：macOS 和 Windows 的行为差异
Linux 用 inotify，macOS 用 kqueue，Windows 用 ReadDirectoryChangesW —— 底层机制不同，导致同一段代码在不同系统表现不一致。最典型的是 macOS 对符号链接默认不追踪目标文件变更，而 Windows 会。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 避免监听软链本身，
watcher.Add("config.yaml")前先用filepath.EvalSymlinks()解析真实路径 - macOS 上
fsnotify.Remove事件不可靠，删除后可能收不到；建议监听父目录，用event.Name匹配 +os.Stat()确认是否真的消失 - Windows 对长路径（>260 字符）支持差，启用 long path 支持需在
go.mod中加//go:build windows注释并确保系统开启策略
资源泄漏：忘记关闭 watcher 的后果
fsnotify.Watcher 是有状态的系统资源封装，不调 watcher.Close() 不仅会泄露 inotify fd（Linux）或 kqueue port（macOS），还会让 goroutine 泄漏——watcher 内部至少维持一个长期运行的读事件 goroutine。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
defer watcher.Close()是最安全的，但要注意 defer 发生在函数 return 之后，若 watcher 在 long-running server 中创建，应绑定到生命周期（如 http.Server.RegisterOnShutdown） - Close 后再向
watcher.Events或watcher.Errors读取会 panic，务必确保所有接收逻辑在 Close 前结束 - 测试时用
runtime.NumGoroutine()对比前后数量，能快速发现 goroutine 泄漏
真正难的不是注册监听，而是理解操作系统如何通知变更、编辑器如何保存文件、以及 fsnotify 如何折中抽象这些差异。每个平台的“正常行为”，在另一个平台都可能是 bug 现象。
