直接用fsnotify监听文件变化可行但生产环境需规避四类问题：事件重复、路径不存在、macOS丢事件、goroutine泄漏；必须监听目录并过滤文件，处理临时文件、原子写入及错误通道，递归监听需安全遍历，macOS下应比对ModTime和Size而非依赖Op。
直接用 fsnotify 监听文件变化并触发重载是可行的，但生产环境里几乎没人裸写——因为事件重复、路径不存在、macOS 丢事件、goroutine 泄漏这四类问题会在第一次上线就暴露。
为什么不能只监听单个配置文件
fsnotify 本身不支持直接监听单个文件；它监听的是目录，靠事件里的 event.Name 过滤目标文件。这意味着：
- 必须先
watcher.Add(filepath.Dir(configPath))，否则 Add 失败且无提示 -
event.Name是相对路径，和configPath比对前得统一用filepath.Base()或filepath.Abs() - 编辑器（如 vim、VS Code）保存时会先写临时文件再
Rename，你会收到Create+Rename两个事件，而非一次Write - 忽略
*.swp、*~、.DS_Store等临时文件必须手动做，fsnotify不提供内置过滤
如何安全处理 fsnotify.Events 和 fsnotify.Errors
这两个 channel 不读就会卡死 watcher，尤其 watcher.Errors —— 一旦写入阻塞，整个监听逻辑停摆。常见错误是只在 select 里读 Events，却把 Errors 放进 default 或直接忽略。
- 必须用
select同时监听两个 channel，且不能加default（否则错失事件） - 关闭 watcher 前，要确保消费 goroutine 已退出，再调
watcher.Close() - 关闭后仍可能有残留事件，需在 Close 后立刻非阻塞读一次
Events和Errors（最多各 1 个），否则可能 panic：“send on closed channel” - 建议封装一个
WatchWithDebounce函数，内部启动独立 goroutine 处理 channel，并支持 100ms 去抖（合并高频 Write）
递归监听整个项目目录的正确姿势
fsnotify 默认不递归，但也不能简单用 filepath.Walk 遍历所有子目录然后全量 Add——权限拒绝、符号链接、挂载点都会导致 panic 或静默失败。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 改用
filepath.WalkDir（Go 1.16+），它可传入fs.DirEntry并跳过权限错误 - 对每个
DirEntry判断entry.IsDir()且!entry.Type().IsSymlink()再watcher.Add(entry.Name()) - 提前过滤掉
vendor、node_modules、.git等目录（用strings.HasPrefix或正则） - 若监听路径含软链接，需明确是否要跟随：默认不跟随；要跟随就得自己
os.Readlink+filepath.EvalSymlinks后再 Add
macOS 上配置热重载失效的典型原因
macOS 的 FSEvents 不上报具体操作类型，event.Op 常为 fsnotify.Chmod 或空，且对原子写入（tmp → rename）响应延迟明显。
- 别依赖
event.Op & fsnotify.Write判断内容变更，改用os.Stat对比ModTime()和Size() - 收到事件后，立即对
event.Name调用os.Stat，若返回os.ErrNotExist，说明是临时文件被删，跳过 - 若旧路径消失 + 新路径出现且大小非零，大概率是编辑器原子替换，此时才真正需要重载
- 不要监听
~/Library/Caches类路径——FSEvents 在某些 macOS 版本中对这些路径有访问限制
最易被忽略的点：所有路径操作必须用 filepath.Clean 标准化，否则在 Windows 下反斜杠、macOS 下大小写敏感路径会导致比对失败；而事件去抖的 timer 必须按文件名粒度维护，不是全局一个 timer——否则改了 config.json 又动了 main.go，后者会拖慢前者的响应。
