fsnotify事件易丢、fd爆炸、macOS模糊、goroutine泄漏：需设缓冲通道、跳过无关目录、校验文件状态、用context控制关闭。
fsnotify 事件通道缓冲不足导致丢事件
fsnotify 内部使用无缓冲 channel 向外投递事件，但你传给 watcher.Events 的 channel 如果容量太小（比如没显式指定或只设为 1），一旦消费不及时，新事件就会被直接丢弃——不是阻塞，是静默丢弃。
- 缓冲大小至少设为
make(chan fsnotify.Event, 100)；100 是经验下限，高频率场景（如日志目录）建议 500 或更高 - 别依赖
for range watcher.Events同步读取：它本质是阻塞式消费，编辑器保存瞬间可能连续触发 3–5 个事件，来不及处理就漏掉 - 必须用独立 goroutine 消费，且该 goroutine 不能有长耗时逻辑（如同步 HTTP 请求、未加超时的数据库写入）
递归监听子目录引发 fd 数量爆炸
Linux 下每个 watcher.Add() 调用都会创建一个 inotify 实例，占用一个文件描述符。手动遍历目录树调用 Add() 时，若目录层级深、子目录多，极易触达 /proc/sys/fs/inotify/max_user_watches 限制，报错 no space left on device。
- 先用
os.Stat()确认路径存在且可读，再调watcher.Add()，避免无效 Add 增加 fd 开销 - 对不需要实时响应的子目录（如
node_modules/、vendor/），跳过添加；可用filepath.Base()过滤常见排除名 - 容器内运行时检查
/dev/inotify是否挂载，缺失则需启动参数加--device=/dev/inotify
macOS 上 FSEvents 导致事件合并与类型模糊
macOS 底层 FSEvents 不区分“内容修改”和“权限变更”，统一返回 fsnotify.Chmod 或空 Op，且对原子写入（先写 tmp 再 rename）响应延迟，容易漏掉 Create + Write 连续事件。
- 判断文件是否真被修改，不能只看
e.Op & fsnotify.Write != 0，要补os.Stat(e.Name)对比ModTime()和Size() - 监听目录时，对
e.Name做后缀过滤：忽略.*.swp、.*~、.DS_Store等临时文件事件 - 收到
Rename事件后，立即对旧路径和新路径都做os.Stat，确认是否为编辑器原子替换（旧路径消失 + 新路径存在且大小非零）
watcher.Close() 不彻底引发 goroutine 泄漏
watcher.Close() 并不会立刻终止所有后台 goroutine。它只是关闭底层 inotify/FSEvents 句柄，但内部仍可能向 watcher.Events 和 watcher.Errors 发送最多各 1 个残留事件。若此时你的消费 goroutine 已退出，就会 panic：send on closed channel。
立即学习“go语言免费学习笔记（深入）”；
- 关闭前，先用
context.WithCancel控制事件消费循环退出，再调watcher.Close() - Close() 后必须非阻塞读完两个 channel：
select { case 和同理读 <code>watcher.Errors - 别在
defer watcher.Close()后直接 return，确保后续有清理逻辑执行空间
