根本原因是fsnotify只监听目录而非文件，且不递归、不捕获原子写入语义；正确做法是监听父目录并在回调中过滤文件名。
为什么 fsnotify 监控不到文件修改？
常见现象是启动监控后，改了 main.go，但没触发回调。根本原因通常是监听路径没指向实际文件所在目录，而是指向了父级空目录或符号链接路径。fsnotify 不会自动递归监听子目录，且对 symlink 的行为因系统而异（Linux 下默认不跟随，macOS 可能表现不同）。
实操建议：
- 用
filepath.Abs("./")获取绝对路径再监听，避免相对路径歧义 - 显式调用
watcher.Add("path/to/dir")，不要只加"."—— 某些 Go 版本下"."在某些 shell 环境中解析异常 - 检查是否遗漏
os.Chmod导致的权限问题（尤其在 Docker 或 WSL 中），fsnotify需要读取目录 inode 权限 - Windows 下注意长路径限制，启用
LongPathsEnabled注册表项或确保路径短于 260 字符
如何让 go build 不阻塞文件监控？
直接在 fsnotify 的 Events channel 回调里执行 exec.Command("go", "build").Run()，会导致后续文件事件堆积甚至丢事件 —— 因为构建过程可能耗时数秒，而监控 goroutine 被阻塞。
正确做法是把构建任务异步化，并做简单去抖：
- 用
time.AfterFunc延迟 300ms 执行构建，避免连续保存触发多次编译 - 每次新事件到来时，先
stopTimer()再新建 timer，保证只响应最后一次修改 - 构建前检查
event.Op&fsnotify.Write != 0，过滤掉Chmod或编辑器临时文件（如main.go~、.#main.go） - 将
cmd.Stdout和cmd.Stderr重定向到io.Discard或日志文件，避免终端输出混乱
air 和手写监控脚本哪个更可靠？
air 是成熟方案，但默认配置容易踩坑：它依赖 .air.toml 中的 watch 列表，若漏写 **/*.go 或误配 build_delay，就会出现“改了代码却不重建”。而手写脚本虽轻量，但需自行处理信号转发（比如 Ctrl+C 后子进程残留）、构建失败时的错误提示收敛、以及多平台二进制名差异（./myapp vs myapp.exe）。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
推荐组合策略：
- 开发初期用
air -c .air.toml快速验证逻辑，配置中明确写出tmp_dir = "./tmp"和bin = "./tmp/app" - 上线前换成自研脚本，去掉所有第三方依赖，只保留
fsnotify+exec+ 简单状态标记 - 无论哪种方式，都加一行
log.Printf("rebuild triggered by %s", event.Name)，便于快速定位监控是否生效
交叉编译环境下如何避免监控失效？
当设置 GOOS=linux GOARCH=arm64 go build 时，生成的二进制文件名和路径与本地运行环境不一致，如果监控逻辑硬编码了 ./myapp 并试图 exec.LookPath 查找，就会失败。更隐蔽的问题是：某些 IDE（如 VS Code）在远程开发容器中，文件变更事件由宿主机发出，但 fsnotify 运行在容器内，挂载方式（如 delegated）可能导致 inotify 事件丢失。
关键应对点：
- 构建目标路径统一用变量控制，例如
binPath := filepath.Join("dist", "app-"+runtime.GOOS+"-"+runtime.GOARCH) - 在 Docker 中启用
inotify支持：确认 base image 包含libinotify1（Debian/Ubuntu）或inotify-tools（Alpine），且挂载时不用cached模式 - CI/CD 中禁用文件监控逻辑，仅保留手动
go build步骤 —— 自动监控只用于本地开发
真正麻烦的不是监听本身，而是不同 OS 对文件系统事件的抽象差异：Linux 用 inotify，macOS 用 kqueue，Windows 用 ReadDirectoryChangesW，fsnotify 底层做了封装，但边界 case（比如 NFS 挂载、WSL2 文件系统桥接）仍需实测验证。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
