fsnotify监听不到文件修改的根本原因是它只监听目录而非文件，且不递归、不捕获原子写入语义；正确做法是监听父目录并在回调中过滤文件名。
fsnotify 为什么监听不到文件修改
根本原因不是 fsnotify 不行，而是它默认只监听目录，不递归、不自动处理子目录变更，更不会捕获“写入完成”语义（比如编辑器先写临时文件再原子替换）。你改了一个文件却没收到事件，大概率是路径注册错了或事件类型没选对。
- 只调用
watcher.Add("file.txt")是无效的——fsnotify要求监听路径必须是目录，文件得靠父目录触发后自己过滤 - 编辑器保存常触发
WRITE+CHMOD+RENAME组合，但你若只检查Op.Write，会漏掉 Vim/VS Code 的临时文件覆盖流程 - Linux 下 inotify 有句柄数限制，默认 8192，大量文件监听时可能静默失败，
errno = Too many open files不一定报错，得查/proc/sys/fs/inotify/max_user_watches
如何正确监听整个目录并过滤目标文件
核心是两步：监听父目录 + 在事件回调里用 filepath.Base 或 strings.HasSuffix 做白名单判断。别试图给每个文件单独 Add，既不可靠又耗资源。
- 监听目录用
watcher.Add("/path/to/dir")，不是文件路径 - 在
select { case event := 中，用 <code>filepath.Base(event.Name)提取文件名，再匹配.go、.yaml等后缀 - 必须同时处理
event.Op&fsnotify.Write != 0和event.Op&fsnotify.Create != 0，否则新建文件或重命名后首次写入收不到 - Windows 下注意路径分隔符，
event.Name返回的是正斜杠格式，但本地路径可能是反斜杠，建议统一用filepath.Clean标准化
fsnotify.Close() 之后还收得到事件？
是的，而且很常见。因为 watcher.Close() 只关闭内部 inotify 实例和发送通道，但已进入 channel 的事件仍会被消费。如果你在 goroutine 里循环读 watcher.Events，关闭后没做退出控制，就会 panic：send on closed channel 或读到 nil 事件。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 关闭前务必先停掉所有读事件的 goroutine，推荐用
context.WithCancel控制生命周期 - 不要依赖
watcher.Events == nil判断是否关闭，channel 关闭后读操作仍可进行，只是返回零值 - 标准做法是在
Close()后立即调用watcher.Events = nil和watcher.Errors = nil，并在 select 分支加default或if watcher.Events == nil防止空指针
macOS 上 fsnotify 延迟高、丢事件怎么办
FSEvents 底层机制导致 macOS 对小文件高频写入（如日志轮转）容易聚合事件或延迟上报，不是 bug，是设计如此。尤其当多个文件在 100ms 内被修改，fsnotify 可能只发一个 Write 事件且 event.Name 为空字符串。
立即学习“go语言免费学习笔记（深入）”；
- 遇到空
event.Name，别直接跳过，要结合event.Op和上一次已知状态做补偿判断 - 避免在回调里做耗时操作（如解析 JSON、调用 HTTP），否则积压事件队列，加剧丢失——开新 goroutine 处理，但记得加限流或缓冲 channel
- 如果必须强一致性，考虑 fallback 到定期
os.Stat检查 mtime，虽然低效但可靠；fsnotify定位是“近实时提示”，不是“精确审计”
