fsnotify.Chmod事件不可靠，必须结合os.Stat轮询与位级比对来安全检测权限变更：先用filepath.Join构造绝对路径，再stat确认存在性与权限位（fi.Mode()&os.ModePerm），并用context控制生命周期。
fsnotify 本身不保证稳定捕获 Chmod 事件，尤其在 macOS 和 Windows 上常被静默忽略或与 Write 混合触发；真正可靠的权限变更感知，必须结合 os.Stat 轮询 + 时间窗口去重，而非依赖单一事件。
为什么 fsnotify.Chmod 事件不可靠
操作系统层面对权限变更的事件上报差异极大：inotify（Linux）通常能发出 IN_ATTRIB，但 fsnotify 将其映射为 Chmod 的同时，可能和 Write、Chown 合并在一个 event 中；FSEvents（macOS）默认不报告纯权限变化，除非显式开启 FileEvents 标志（fsnotify 当前未暴露该能力）；ReadDirectoryChangesW（Windows）则完全不通知 chmod 类操作。
-
event.Op & fsnotify.Chmod != 0在 Linux 下可能命中，但在 macOS/Windows 下几乎永远为 false - 即使命中，也常伴随
Write或Chown，无法区分“是 chmod 还是编辑器保存顺带改了权限” - 某些 NFS 或加密卷（如 iCloud Drive）会彻底屏蔽属性变更事件
如何安全检测文件权限位真实变更
放弃对 Chmod 事件的强依赖，改用“低频 Stat + 增量比对”策略：只对已知关注的文件路径定期调用 os.Stat，提取 os.FileInfo.Mode()，与上一次快照做位级比对（重点看 0777 部分）。
- 轮询间隔建议 ≥100ms，避免频繁
stat拖慢 I/O；对高敏感场景可用time.Ticker控制节奏 - 缓存上次
Mode()时务必用fi.Mode() & os.ModePerm，过滤掉os.ModeDir、os.ModeSymlink等非权限位 - 若发现变更，再触发业务逻辑（如拒绝加载、记录审计日志），而非在
fsnotify事件循环中直接响应 - 可复用已有 watcher 的 goroutine，避免额外 goroutine 开销：在 select default 分支里插入 stat 检查
监听目录时如何避免 chmod 误报干扰
当监听的是父目录（如 watcher.Add("/etc")），收到的 Chmod 事件可能来自目录自身（如 chmod 755 /etc），也可能来自子项（如 chmod 600 /etc/passwd），但 event.Name 在后者中是 "passwd"，无法直接得知权限是否真变了——因为 os.Stat(event.Name) 拿到的是相对路径，需拼完整路径再 stat。
- 所有
event.Name必须先通过filepath.Join(watchedRoot, event.Name)构成绝对路径，再os.Stat - 对
event.Op & fsnotify.Chmod != 0的事件，仍要os.Stat确认目标存在且可读，否则可能是已删除文件残留事件 - 跳过临时文件名（
strings.HasSuffix(event.Name, "~")、strings.Contains(event.Name, ".swp")），它们的 chmod 无业务意义
关闭 watcher 前必须清理 chmod 监控状态
watcher.Close() 不会自动停止你手动加的 os.Stat 轮询逻辑。若 goroutine 仍在运行，可能对已释放路径反复 stat，导致 no such file or directory 错误堆积。
立即学习“go语言免费学习笔记（深入）”；
- 用
context.WithCancel控制 stat 循环生命周期，watcher.Close()前先cancel() -
watcher.Close()后，仍需非阻塞读一次watcher.Events和watcher.Errors，防止残留事件写入已关闭 channel - Stat 缓存 map 若为全局变量，关闭时应清空或标记失效，避免后续 goroutine 误用陈旧快照
os.Stat 才是判决依据——这个判断过程不能省，也不能外包给 fsnotify。 
