fsnotify无法监听chmod/chown事件，因其底层依赖的系统接口（如Linux inotify）不报告权限或所有者变更；macOS需显式启用WatchFlagAttrib，Linux则需轮询os.Stat()或调用inotifywait，Windows须降级为Stat轮询并比对文件属性。
为什么 fsnotify 无法监听文件属性变更（如 chmod、chown）
fsnotify 默认不触发 CHMOD 或 CHOWN 类事件——它底层依赖 inotify（Linux）、kqueue（macOS）或 ReadDirectoryChangesW（Windows），而这些系统接口对元数据变更的支持极有限。Linux 的 inotify 根本不报告权限/所有者变化；macOS 的 kqueue 虽能捕获 NOTE_ATTRIB，但 fsnotify 默认未启用该标志。
如何让 fsnotify 捕获 chmod/chown 事件（Linux/macOS）
必须显式启用 FSNotifyAttrib（macOS）或改用内核级替代方案（Linux）。macOS 上可直接设置：
watcher, _ := fsnotify.NewWatcher()
watcher.Add("/path/to/file")
// 启用属性变更监听（仅 macOS 有效）
watcher.SetWatchFlags(fsnotify.WatchFlagAttrib)
Linux 下无原生支持，需退而求其次：用 inotifywait -m -e attrib 外部命令 + os/exec 拉取输出，或轮询 os.Stat() 对比 Mode() 和 Sys().(*syscall.Stat_t).Uid/Gid ——但轮询间隔需权衡精度与开销。
- 轮询建议间隔 ≥100ms，避免 CPU 暴涨
- 对比时注意：Linux 中
os.FileMode不含 setuid/setgid 位，需从syscall.Stat_t.Mode提取完整权限 - chown 后的 GID/UID 变更必须通过
syscall.Stat_t获取，os.FileInfo的Uid()/Gid()在 Go 1.22+ 才稳定返回
回调函数里如何安全处理并发属性变更
同一文件可能在短时间内被多次 chmod/chown，fsnotify 或轮询可能触发重复事件。直接在回调里执行耗时操作（如写日志、发 HTTP 请求）会导致堆积甚至 goroutine 泄漏。
立即学习“go语言免费学习笔记（深入）”；
- 用
sync.Map缓存最近一次变更时间戳，相同路径 500ms 内重复事件直接丢弃 - 回调中只做轻量操作：更新内存状态、发 channel 信号，重逻辑交给单独 goroutine 串行处理
- 避免在回调里调用
os.Chmod()等可能再次触发监听的操作，否则形成循环
跨平台兼容性陷阱：Windows 上的 attrib 事件不可靠
Windows 的 ReadDirectoryChangesW 对 FILE_NOTIFY_CHANGE_ATTRIBUTES 支持不稳定，尤其对 NTFS 权限变更（ACL 修改）几乎不触发。实测中：chmod 在 WSL2 下可用，原生 Windows 命令行 icacls 或资源管理器修改 ACL 通常无通知。
若必须支持 Windows 属性监控，唯一可靠方式是定期调用 os.Stat() + 深度比较 syscall.Win32FileAttributeData 中的 FileAttributes 和 CreationTime 字段——但要注意：Windows 文件属性变更（如只读位）可能不更新 ModifyTime，必须单独比对 FileAttributes。
