fsnotify默认不递归、不处理原子写入、不校验路径，导致漏事件、收脏事件、静默失败；必须监听父目录、手动遍历子目录add、同时处理write/rename事件、校验路径有效性并消费events/errors通道。
直接监听目录可行，但fsnotify.Watcher不递归、不自动处理原子写入、不校验路径有效性——漏事件、收脏事件、静默失败，基本是默认配置下的必然结果。
为什么watcher.Add("config/")收不到子目录文件修改
因为fsnotify只监听显式注册的路径节点，watcher.Add("config/")仅响应config/目录自身的元数据变更（如被mv或chmod），对config/db.yaml的写入完全无感。
- 必须手动遍历：用
filepath.WalkDir("config/", ...)，对每个entry.IsDir()为true的路径调用watcher.Add(path) - 跳过符号链接：检查
entry.Type() & os.ModeSymlink != 0，否则可能触发权限错误或无限递归 - Linux 注意系统限制：
/proc/sys/fs/inotify/max_user_watches超限会报too many open files，需提前调大 - macOS 深层嵌套（>100 层）可能触发
kqueue溢出，需捕获fsnotify.ErrEventOverflow
编辑器保存后收不到有效事件？大概率是原子写入没处理
Vim、VS Code 等默认先写config.yaml~或.config.yaml.tmp，再rename覆盖原文件。此时原 inode 失效，Write事件根本不会落在目标文件上。
- 必须同时监听
fsnotify.Write和fsnotify.Rename，且优先响应后者：用if event.Op&fsnotify.Rename != 0 && filepath.Base(event.Name) == "config.yaml" - 过滤临时文件：
strings.HasSuffix(event.Name, "~")、strings.HasSuffix(event.Name, ".swp")、strings.HasSuffix(event.Name, ".tmp") - 收到事件后立刻
os.Stat(event.Name)，确认文件存在、大小非零——避免处理残留临时文件 - 别用
strings.Contains(event.String(), "RENAME")判断事件类型，不可靠；位运算是唯一正确方式
watcher.Add("file.txt")为什么没反应
fsnotify底层依赖操作系统事件机制（inotify/kqueue/ReadDirectoryChangesW），这些机制本身就不支持监听单个文件路径。传入文件路径会导致静默失败（Linux/macOS）或 panic（Windows）。
- 正确做法：监听父目录，即
watcher.Add(filepath.Dir("file.txt")) -
event.Name是相对路径（如"file.txt"），比对时用filepath.Base(event.Name) == "file.txt"，不要字符串匹配全路径 - 若路径含软链，先
filepath.EvalSymlinks("file.txt")解析真实路径，再取Dir，否则监听注册到链接自身而非目标 - 监听前务必
os.Stat校验路径存在且为目录，否则Add()可能返回nil错误却无提示
Events和Errors通道不消费就卡死
watcher.Events和watcher.Errors都是无缓冲 channel。没人读，写事件就会阻塞整个 watcher —— 新事件进不来，旧事件丢掉，最终监听失效。
- 必须启动 goroutine 持续读取：
go func() { for range watcher.Events { ... } }() - 不能只读
Events忽略Errors：权限不足、路径被删等错误会持续写入Errors，不读会阻塞 - 重复调用
watcher.Add()同一路径会 panic，加锁或维护已监听路径集合做去重 - 程序退出前必须调
watcher.Close()，否则 fd 泄露，尤其长期运行服务
真正难的不是写几行监听代码，而是把路径存在性、符号链接解析、原子写入兜底、递归注册并发安全、系统资源上限这五件事全串起来——少一个，线上就静默失灵。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
