fsnotify 无法直接监听单个文件路径，必须监听其所在目录并按 event.name 过滤；需同时监听 write 和 rename 事件，优先响应 rename 以捕获编辑器原子写入的最终状态；watcher.events 必须用带缓冲 channel 消费，避免丢事件。
fsnotify 监听单个文件路径（如 "config.yaml"）基本无效，必须监听其所在目录，并在事件回调中按 event.Name 过滤——否则编辑器原子写入、临时文件覆盖、符号链接跳转都会导致事件丢失或静默失败。
为什么 watcher.Add("config.yaml") 没反应
不是代码写错，而是 fsnotify 底层不支持监听纯文件路径。Linux 的 inotify、macOS 的 kqueue、Windows 的 ReadDirectoryChangesW 全部只接受目录句柄。调用 watcher.Add("config.yaml") 在多数系统上会返回 no such file or directory 或静默失败，但你没检查错误就继续了。
- 必须改用
watcher.Add(filepath.Dir("config.yaml"))，且确保该目录存在、有读权限 - 若路径含软链，先用
filepath.EvalSymlinks()解析真实路径再取Dir，否则监听可能注册到错误位置 -
event.Name是相对路径（如"config.yaml"），不能直接和绝对路径比对，推荐用filepath.Base(event.Name) == "config.yaml"
如何可靠捕获编辑器保存后的最终内容
Vim、VS Code 等默认启用原子写入：新建临时文件（如 .config.yaml123456）→ 写入 → Rename 覆盖原文件。此时原 inode 被销毁，仅监听 Write 会收到脏数据或根本无事件。
- 必须同时监听
fsnotify.Write和fsnotify.Rename，且优先响应后者——Rename才代表“覆盖完成” - 判断逻辑应为：
if event.Op&fsnotify.Rename != 0 && filepath.Base(event.Name) == "config.yaml" - 某些编辑器（如 macOS TextEdit）还会夹带
Chmod，别用字符串匹配event.String()，必须用位运算判断操作类型 - 收到事件后，立刻
os.Stat(event.Name)确认文件存在且非空，跳过*~、.swp、.tmp等临时名
watcher.Events 为什么总丢事件
watcher.Events 是无缓冲 channel，内部 goroutine 向它发事件时，若无人消费就会阻塞，后续事件被丢弃甚至引发死锁。
- 必须用带缓冲的中转 channel，例如
events := make(chan fsnotify.Event, 100) - 另起 goroutine 拉取
watcher.Events并转发到events，避免阻塞 watcher 内部逻辑 - 永远检查
event.Op的位掩码，不要写event.Op == fsnotify.Write——一个事件可能同时含Write | Chmod - 关闭 watcher 前，必须先停掉所有读
Events的 goroutine，否则会 panic：send on closed channel
跨平台和递归监听的硬伤怎么绕
Linux、macOS、Windows 底层机制不同，同一段代码行为不一致是常态。递归监听更是完全不内置，全靠手动补。
- macOS 上
fsnotify.Remove不可靠，删除后常收不到；建议监听父目录 + 用os.Stat()主动确认是否消失 - Windows 对长路径（>260 字符）支持差，需在
go.mod加//go:build windows注释并确保系统开启长路径策略 - 递归监听子目录必须手动实现：启动时用
filepath.WalkDir()遍历所有子目录并逐个watcher.Add()；运行时收到Create且event.IsDir()为真时，立即watcher.Add(event.Name) - 遍历时跳过符号链接：
if entry.Type()&os.ModeSymlink != 0，否则可能触发权限错误或无限循环
fsnotify 在不同编辑器、不同操作系统、不同文件变更节奏下都稳定吐出“这次确实是最终修改”的信号——它本身只负责转发内核事件，语义要你自己拼。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
