fsnotify 是监听文件变化的唯一实用选择，它跨平台封装底层机制，避免轮询缺陷，需手动递归监听子目录、用位运算判断事件类型，并务必关闭 Watcher 防止 fd 泄露。
用 fsnotify 监听文件变化最靠谱
Go 标准库不提供跨平台文件监听能力，fsnotify 是事实标准，不是“可选方案”，是唯一实用选择。它封装了 inotify（Linux）、kqueue（macOS）、ReadDirectoryChangesW（Windows）底层机制，省去你自己写 syscall 的麻烦。
常见错误是直接用 os.Stat 轮询——CPU 白耗、延迟高、错过瞬时修改。还有人试图用 time.AfterFunc + 每秒读一次 ModTime()，这在日志轮转、编辑器保存瞬间极易漏事件。
实操建议：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
go get github.com/fsnotify/fsnotify安装，别自己造轮子 - 监听路径必须存在，
fsnotify.Watcher不会自动创建父目录 - 注册监听后，务必启动 goroutine 读取
w.Events和w.Errors通道，否则事件会阻塞甚至丢失 - 对同一路径重复调用
w.Add()会 panic，加前先检查是否已监听
监听子目录要手动递归添加
fsnotify 默认不递归，这是设计使然，不是 bug。你 w.Add("config/") 只监听该目录自身事件（比如被 mv 或 chmod），不会收到 config/db.yml 的修改通知。
立即学习“go语言免费学习笔记（深入）”；
真实场景里，配置热加载、模板重载、静态资源监控都需要子目录穿透。但 fsnotify 不提供 recursive: true 参数，得自己处理。
实操建议：
- 用
filepath.WalkDir遍历目录树，对每个IsDir()为 true 的路径调用w.Add() - 注意符号链接：默认跳过，如需跟随，改用
filepath.Walk并自行判断os.ModeSymlink - 新增子目录时，仅靠
fsnotify.Create事件不够——你得在收到该事件后，主动w.Add(新路径)，否则后续改动收不到 - macOS 上对深层嵌套目录（>100 层）可能触发 kqueue 限制，需捕获
fsnotify.ErrEventOverflow
区分文件修改、重命名和删除的典型误判
fsnotify.Event 的 Op 字段是位掩码，不是单值枚举。常见错误是写 if e.Op == fsnotify.Write，结果漏掉 fsnotify.Chmod | fsnotify.Write 这类组合操作。
更隐蔽的问题是编辑器行为：VS Code、vim 等保存文件时，常先写临时文件（.foo.swp 或 foo~），再原子 rename 替换原文件。这时你收到的是 Rename 事件，不是 Write；如果只响应 Write，就永远感知不到保存动作。
实操建议：
- 用位运算判断：
if e.Op&fsnotify.Write != 0，而不是== - 对
fsnotify.Rename和fsnotify.Remove做兜底处理，尤其当目标文件名匹配你关心的模式时 - 避免依赖
e.Name后缀判断类型——有些工具（如 go mod download）会生成临时文件但不带点，名字和正式文件完全一样 - Linux 下 inotify 可能合并多次写入为一个事件，
Write事件不代表“内容已落盘”，如需强一致性，得配合f.Sync()或监听 close_write
进程退出前必须 Close Watcher
忘记调用 w.Close() 不只是内存泄漏，更会导致文件描述符持续占用。Linux 默认单进程最多打开 1024 个 fd，监听 10 个目录就占 10 个，反复启停几次就 too many open files。
另一个坑是：goroutine 里读 w.Events 时，如果主流程已 Close()，通道会关闭，但你的循环若没检查 ok 就直接解包，会 panic。
实操建议：
- 用
defer w.Close()放在newWatcher之后，哪怕中间出错也要关 - 读事件循环必须这样写：
for {<br> select {<br> case event, ok := <-w.Events:<br> if !ok { return } // watcher closed<br> handle(event)<br> case err, ok := <-w.Errors:<br> if !ok { return }<br> log.Println("watch error:", err)<br> }<br>} - 测试时用
lsof -p $(pidof yourapp)确认无残留inotifyfd
真正难的不是监听本身，而是处理编辑器的 rename 花样、系统级文件移动、权限突变这些边缘情况——它们不会报错，但会让你的热加载逻辑静默失效。
