必须监听父目录而非文件路径，因系统API仅支持目录监听；需处理Rename事件捕获原子写入的最终内容，并用goroutine消费Events通道防丢事件。
直接监听单个文件路径（如 "config.yaml"）基本无效，必须监听其父目录并手动过滤事件；否则编辑器原子写入、临时文件、重命名都会导致事件丢失或误判。
为什么 watcher.Add("config.yaml") 没反应
fsnotify 底层依赖 inotify/kqueue/ReadDirectoryChangesW，这些系统机制只支持监听**目录节点**，不接受纯文件路径。调用 watcher.Add("config.yaml") 在 Linux/macOS 下常静默失败（返回 "no such file or directory" 或更隐蔽的 "invalid argument"），Windows 甚至可能 panic。
- 必须改用
watcher.Add(filepath.Dir("config.yaml"))，即监听其所在目录 - 若路径含软链，先用
filepath.EvalSymlinks()解析真实路径再取Dir，否则监听可能失效 -
event.Name是相对路径（如"config.yaml"），需和目标文件名做比对，推荐用filepath.Base(event.Name) == "config.yaml"
如何正确捕获编辑器保存后的“最终内容”
Vim、VS Code 等默认使用原子写入：先写临时文件（如 .config.yaml654321），再 Rename 覆盖原文件。此时原 inode 被丢弃，仅监听 Write 会读到脏临时文件，或根本收不到事件。
- 必须同时关注
fsnotify.Write和fsnotify.Rename，且优先响应后者——Rename才代表“覆盖完成” - 判断逻辑应为：
if event.Op&fsnotify.Rename != 0 && filepath.Base(event.Name) == "config.yaml" - 某些编辑器（如 macOS 上的 TextEdit）还会夹带
Chmod，别用strings.Contains(event.String(), "RENAME")判断，而要用位运算
watcher.Events 不消费就会丢事件
watcher.Events 是无缓冲 channel，不加 goroutine 消费会阻塞内部读取逻辑，最终丢事件。这不是代码写错，而是 fsnotify 的设计使然——底层 inotify/kqueue 队列有大小限制，一旦写满就溢出丢弃。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 必须起独立 goroutine 拉取：
go func() { for { select { case event, ok := - 生产环境建议加缓冲中转，例如
events := make(chan fsnotify.Event, 100)，避免高并发下瞬时积压 -
watcher.Close()会立即关闭Events和Errors两个 channel，务必确保所有读取 goroutine 已退出，否则可能 panic 或死锁
递归监听子目录必须手动实现
fsnotify.Watcher.Add() 默认不递归，watcher.Add("/a") 只监听 /a 目录本身的元数据变化（如被重命名），对其下 /a/b/ 或 /a/b/c.txt 的改动完全无感。
- 启动时全量注册：用
filepath.WalkDir(root, ...)遍历所有子目录，对每个d.IsDir()为 true 的路径调watcher.Add(path) - 运行时动态响应：在事件循环中监听
fsnotify.Create，并用event.IsDir()判断是否为新目录，是则立刻watcher.Add(event.Name) - 注意加锁：多个 goroutine 可能并发调
Add，需用sync.Mutex保护 - 跳过符号链接：
entry.Type() & os.ModeSymlink != 0，否则可能触发权限错误或死循环
真正容易被忽略的是：事件不是“一次一文件”的确定性通知，而是内核异步投递的流式信号——同一保存动作可能触发 Create → Write → Rename → Chmod 多个事件，且顺序、组合、跨平台表现都不稳定。业务逻辑不能依赖某类事件一定出现，而要围绕“文件内容是否已稳定可读”做判断，比如结合 os.Stat().ModTime() 或简单 sleep 后重试读取。
