必须用fsnotify，因其跨平台封装inotify/kqueue/ReadDirectoryChangesW，避免syscall.Inotify*的fd泄漏、事件解析错误、非递归缺陷及轮询丢事件等问题；Add()需检查返回error，监听目录而非文件并过滤event.Name，正确处理符号链接、路径分隔符与写入完成判断。
Go 没有原生 inotify 支持，fsnotify 是唯一可行、跨平台、生产就绪的选择；所谓“Go-Inotify”只是对底层机制的误称，实际不能直接用 syscall 封装替代。
为什么不能直接用 syscall.Inotify_*
手动调用 syscall.InotifyInit、syscall.InotifyAddWatch 看似底层可控，但极易引发以下问题：
-
inotify_init返回的 fd 必须显式syscall.Close，漏关会导致 fd 泄漏，进程最终被系统 kill（too many open files） -
read系统调用返回的是原始字节流，需手动解析unix.InotifyEvent结构体：字段偏移、长度对齐、事件名截断都容易出错 -
inotify本身不支持递归监听，监听/a不会收到/a/b/c.txt的事件，必须自己遍历子目录并逐个AddWatch - macOS 和 Windows 完全不认
inotify，写死 syscall 就等于放弃跨平台——而 Go 的核心优势之一就是跨平台
fsnotify.Add() 必须检查返回 error
watcher.Add(path) 不是“尽力而为”，它在路径不存在、权限不足、或超出内核限制时会立即返回 error。忽略它会导致后续读 watcher.Events 时 channel 关闭、goroutine 退出，整个监听静默失效。
- 监听目录时，进程需对目录有
read权限（否则无法获取子项变更） - 监听单个文件时，只需
read权限即可监听修改，write权限非必需 - 符号链接默认不跟随，若想监听目标文件内容，应先
filepath.EvalSymlinks(path)再Add - Linux 上受
/proc/sys/fs/inotify/max_user_watches限制，大批量监听报no space left on device时，需提前调整该值
监听目录而非文件 + 过滤 event.Name
监听单个文件（如 watcher.Add("config.yaml")）是高危操作：编辑器原子写（先写 config.yaml~ 再 rename）、mv、git checkout 都会让原路径失效，监听即中断。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法是监听父目录：
watcher.Add("configs/") - 在事件处理中用
filepath.Base(event.Name)或filepath.Ext(event.Name)过滤目标文件 - 注意
event.Name是相对路径（如"configs/app.json"），不是绝对路径，勿用strings.Contains(event.Name, "/")判断层级 - Windows 下
event.Name使用\分隔，统一用filepath.Clean()处理，避免平台差异
Write 事件不等于文件已写完
收到 event.Op & fsnotify.Write 仅表示内核通知了写入动作，不代表文件内容已落盘、大小已稳定、或编辑器已完成保存流程。
- VS Code、vim 等默认启用原子写：先写临时文件，再
rename—— 此时更可靠的信号是event.Op & fsnotify.Rename - 上传或解析前，应对
event.Name调用os.Stat()，确认Size()和ModTime()在 100ms 内未变化 - 大文件（>1MB）建议计算
sha256.Sum256校验完整性，小文件可只比对ModTime和Size - 所有 I/O 操作（打开、读取、上传）必须带
context.WithTimeout，防止因文件锁、NFS 卡顿等导致 goroutine 挂起
真正难的不是监听到事件，而是判断“这个事件是否代表业务上一次可靠的变更完成”。路径合法性、事件聚合时机、文件状态稳定性、跨平台路径处理——这些细节堆叠起来，才是线上服务不出问题的关键。
