最稳妥的方式是调用 os.Stat 获取 os.FileInfo 接口，而非直接操作 syscall.Stat_t；需用 Mode().Perm() 提取权限、ModTime() 获取时间，并用 IsDir() 等方法判断类型，避免位运算和纳秒级相等比较。
用 os.Stat 读取文件元信息，别直接操作 syscall.Stat_t
Go 中获取权限和修改时间，最稳妥的方式是调用 os.Stat，它返回 os.FileInfo 接口。自己去调用底层 syscall.Stat 容易漏掉平台差异（比如 Windows 的 mtime 精度、Unix 的纳秒支持），也绕过了 Go 对符号链接的默认处理逻辑。
常见错误现象：os.Lstat 和 os.Stat 混用导致读到的是链接本身还是目标文件的权限搞反；或者用 unsafe 强转 FileInfo 底层结构体，结果在不同 Go 版本间崩溃。
-
os.Stat跟随符号链接，os.Lstat不跟随 —— 权限判断前先想清楚你关心的是链接文件本身，还是它指向的目标 -
FileInfo.Mode()返回os.FileMode，不是原始整数，别用&直接跟八进制字面量比（如0755），要用Perm()方法提取权限位 - 修改时间通过
FileInfo.ModTime()获取，类型是time.Time，不是秒数或纳秒整数 —— 需要比较或格式化时直接用time.Time方法
os.FileMode 不是 chmod 数字，它的底层是 uint32 但语义已封装
os.FileMode 看起来像 0644，但它本质是带标志位的类型：低 12 位存 Unix 权限，高位存目录、设备、套接字等类型标识。直接拿 uint32(fmode) 去做 fmt.Printf("%o", ...) 可能显示 100644（多了 100000 表示普通文件），这不是 bug，是设计如此。
使用场景：判断是否可执行、是否为目录、是否为符号链接，都该用对应方法，而不是位运算硬解。
立即学习“go语言免费学习笔记（深入）”；
- 判断是否为目录：
fi.Mode().IsDir()，不是fi.Mode()&os.ModeDir != 0（虽然也能 work，但可读性差且忽略类型组合） - 提取纯权限位（用于日志或对比）：
fi.Mode().Perm()，它只返回低 9 位，fi.Mode().Perm() == 0644才安全 - 判断是否可执行：
fi.Mode().Perm()&0111 != 0，注意是0111（八进制），不是0x111；Go 的os.FileMode字面量默认八进制
FileInfo.ModTime() 在不同文件系统上精度不一致，别依赖纳秒级相等
ModTime() 返回的 time.Time 在 ext4 上可能精确到纳秒，在 NTFS 或某些网络文件系统（如 NFSv3）上可能只到秒级，甚至有 2 秒偏差。直接用 == 比较两个 ModTime() 结果，在跨平台或挂载远程存储时大概率出错。
性能影响：调用 ModTime() 本身无额外系统调用（信息已在 os.Stat 一次性读入），但频繁做纳秒级比较会掩盖实际精度限制。
- 需要判断“是否更新过”：用
t1.After(t2)或t1.Sub(t2) > 0，比==更健壮 - 需要容忍误差（比如同步工具）：用
t1.Sub(t2).Abs() 判定“基本一致” - 别把
ModTime().UnixNano()存数据库当唯一依据 —— 同一文件在不同机器上 Stat 出来可能差几纳秒，纯属正常
Windows 下没有“用户/组权限位”，Perm() 返回值只是模拟
Windows 文件系统（NTFS）原生不使用 Unix-style rwx 位，Go 的 os.FileMode.Perm() 在 Windows 上返回的是基于 ACL 的启发式映射（比如 Owner 允许写就设 0200），不可靠。如果你的程序需跨平台做权限校验，别依赖 Perm() 的具体数值。
容易踩的坑：在 Windows 上测试时发现 fi.Mode().Perm() == 0666 成立，上线 Linux 就失败；或者用 chmod 类逻辑去“还原”权限，结果在 Windows 上静默失效。
- 真正需要控制访问时，用
os.Chmod（它在 Windows 上会尝试设置 ACL）而不是手动拼os.FileMode - 仅作展示用途（如
ls -l模拟）：Windows 下可接受Perm()的近似值，但加注释说明“非真实权限位” - 涉及安全决策（如“是否允许上传执行文件”）：必须走系统级 ACL 检查，不能只看
Perm()
