回调不触发的主因是fsnotify默认不递归监听且权限不足；需手动遍历子目录逐个add，用绝对路径并确保读权限，事件判断须用位运算而非等于号。
用 fsnotify 监听文件变化时，为什么回调不触发？
绝大多数情况是监听路径没加递归或权限不足。fsnotify 默认只监听指定目录本身，不自动进入子目录；如果监听的是软链接且没权限读目标路径，也会静默失败。
- 确保用
watcher.Add()添加的是绝对路径，相对路径在 daemon 场景下容易失效 - 递归监听必须手动遍历子目录并逐个
Add()，fsnotify 不提供开箱即用的递归 API - Linux 下需确认进程有读取目标目录的权限（
read），macOS 上对某些系统路径（如/private/var/folders）可能受限 - 监听前先
os.Stat()检查路径是否存在且可访问，避免no such file or directory错误被吞掉
如何区分文件创建、修改、删除事件并安全回调？
fsnotify 的 event.Op 是位掩码，不能直接用 == 判断单一操作，否则会漏掉组合事件（比如 Write + Chmod 同时发生）。
- 用位运算判断：检查
event.Op&fsnotify.Write == fsnotify.Write而不是event.Op == fsnotify.Write - 文件重命名（
Rename）会触发两次事件：原路径的Remove和新路径的Create，需用文件 inode 或内容哈希做去重，否则回调重复执行 - 写入临时文件再原子替换（如编辑器常用模式）会导致先触发
Create再Remove原文件，实际业务中应监听最终稳定文件名，而非临时名（如config.json.tmp） - 回调函数里避免阻塞操作——fsnotify 事件队列有默认缓冲区（256），长时间阻塞会导致丢事件；建议把耗时逻辑扔进 goroutine 或 channel 异步处理
监听多个路径时，怎样避免重复初始化 watcher？
一个 fsnotify.Watcher 实例就能监听任意数量路径，反复调用 fsnotify.NewWatcher() 会浪费 fd 且增加内核开销。
- 全局复用单个
watcher实例，用watcher.Add(path)动态增删路径 - 删除路径用
watcher.Remove(path)，注意它不会阻塞，但后续该路径事件仍可能从 channel 中流出，需在回调里加路径白名单过滤 - 监听路径含通配符（如
**/*.log）需自行 glob 展开，fsnotify 不解析 shell 通配符 - 进程重启时，旧 watcher 的 fd 会释放，无需手动 close；但异常退出前应显式
watcher.Close()防止 fd 泄露
Windows 下监听大目录为什么卡顿或漏事件？
Windows 的 ReadDirectoryChangesW API 对深度嵌套或文件数极多的目录响应慢，且默认单次返回事件上限为 64KB，超限部分会被截断。
- 增大 buffer：创建 watcher 时传入
fsnotify.WithBufferSize(65536)（需 fsnotify v1.9.0+） - 避免监听整个
C:\或用户主目录这种海量文件路径，按业务收敛到具体子目录（如C:\app\logs） - Windows 不支持
fsnotify.Chmod事件，Write事件可能包含多次小写入合并，无法精确对应单次 save 操作 - 测试时用
robocopy或echo > file触发事件，别依赖资源管理器右键“新建文本文档”，它可能走不同 I/O 路径
