fsnotify不支持递归监听，需手动遍历目录并调用add()，同时捕获create事件动态添加新目录，注意跨平台差异与事件去重。
fsnotify 本身不支持递归监听
直接调用 watcher.Add("path") 只会监听指定目录一层，子目录里的新建、修改、删除事件完全收不到。这不是你配置错了，是 fsnotify 底层设计如此——它封装的是操作系统原生 inotify（Linux）、kqueue（macOS）、ReadDirectoryChangesW（Windows），这些 API 本身就只提供单层监听能力。
所以必须手动遍历子目录，对每一层都调用 Add()。但别急着写递归 filepath.WalkDir 然后全加进去：实际运行中会遇到权限拒绝、符号链接循环、挂载点越界等问题，导致监听失败甚至 panic。
- 先用
filepath.WalkDir遍历，但遇到os.ErrPermission或os.ErrNotExist要跳过，不要中断整个遍历 - 对每个目录路径调用
watcher.Add()前，先os.Stat确认它是目录且可读，避免把文件误加进监听（会报no such file or directory） - 跳过符号链接目标（除非明确需要），否则可能重复监听同一目录或陷入循环
监听期间新增子目录不会自动生效
你启动监听时加了 a/b 和 a/b/c，之后在 a/b 下新建 d/，这个 d/ 不会自动被监听——fsnotify 不会感知“目录创建”事件后再去递归加它，除非你主动捕获 fsnotify.Create 事件并判断是否为目录，再手动 Add()。
这正是递归监听最易漏的环节：静态初始化只管“当前快照”，动态变化要靠事件驱动补全。
立即学习“go语言免费学习笔记（深入）”；
- 在事件处理循环里，对每个
event.Op & fsnotify.Create != 0的事件，用os.Stat检查event.Name是否为目录 - 如果是目录，立即
watcher.Add(event.Name)；失败就记录日志，别 panic - 注意 Windows 下重命名目录可能触发两次 Create（临时名 + 正式名），需做简单去重，比如缓存最近 1 秒内的目录名
跨平台行为差异会让测试变脆弱
macOS 的 fsevents 后端默认批量合并事件、延迟高，且对符号链接和 NFS 挂载行为不一致；Windows 的 ReadDirectoryChangesW 对长路径、权限变更更敏感；Linux 的 inotify 则有 inotify watch limit 限制，默认通常只有 8192 个，深层嵌套目录很容易打满。
这意味着你在 macOS 本地测得好好的，部署到 Linux 服务器可能直接报 too many open files 或静默丢事件。
- Linux 上上线前务必检查
/proc/sys/fs/inotify/max_user_watches，必要时用sudo sysctl -w fs.inotify.max_user_watches=524288提升 - 避免监听整个
/home或/var/log这类路径，缩小范围，用通配过滤（如只加**/*.go对应目录） - macOS 开发时加
fsnotify.WithBufferSize(64)降低延迟，但别设太大，内存占用会上去
事件重复和丢失不是 bug，是机制使然
同一个文件保存，你可能收到 2–3 次 Write 事件（编辑器先写临时文件再 rename）；快速连续创建多个文件，可能只收到一次 Create（底层批量通知）。这不是 fsnotify 的问题，是文件系统事件抽象层的固有特性。
业务逻辑如果依赖“每个文件变更只触发一次”，就得自己做 dedupe：基于文件路径 + 事件类型 + 时间窗口（如 100ms 内同路径同类型只留最后一次）。
- 用
map[string]time.Time缓存最近触发过的路径，写入前先查是否在窗口内 - rename 类操作会触发
Create+Remove，若需追踪文件移动，得把两个事件关联起来（看是否同 inode 或内容哈希） - 不要在事件回调里做耗时操作（如解析大文件），起 goroutine 异步处理，否则阻塞监听队列
