Go 中 os.FileInfo 不含 UID/GID 是因跨平台设计，Windows 无此概念；应使用 golang.org/x/sys/unix.Stat 直接调用系统调用获取 *unix.Stat_t 结构体，再安全断言并校验 UID/GID 字符串合法性。
Go 里 os.Stat 返回的 os.FileInfo 接口不带 UID/GID，这不是 bug，是设计使然——它必须跨平台，而 Windows 没有传统 UID/GID 概念。真要拿到 Linux/macOS 下文件的属主信息，得绕过抽象层，直取系统调用返回的原始结构。
为什么 fi.Sys() 不能直接断言成 *syscall.Stat_t
Go 1.19+ 已弃用 syscall 包中的 Stat_t 类型，硬写 fi.Sys().(*syscall.Stat_t) 在新版本会编译失败。更关键的是，fi.Sys() 返回的是 interface{}，类型不确定：在 Unix 系统上可能是 *unix.Stat_t，在 Windows 上是 *syscall.Win32FileAttributeData，不做类型检查就强转必 panic。
- 必须先用类型断言加
ok判断：if st, ok := fi.Sys().(*unix.Stat_t); ok { ... } - 导入必须是
golang.org/x/sys/unix，不是syscall - Windows 下该断言永远为
false，别试图在那里取Uid/Gid（它本来就没有）
unix.Stat() 比 os.Stat().Sys() 更可靠
用 os.Stat() 再从 FileInfo.Sys() 提取，本质仍是走标准库封装路径，中间多一层间接；而 unix.Stat(path, &st) 是直接调系统调用，字段完整、无歧义，且返回值就是你要的 unix.Stat_t 结构体。
- 避免类型断言失败风险：
err := unix.Stat("foo", &st)成功后st.Uid和st.Gid可直接用 - 注意传参是
*unix.Stat_t，不是*syscall.Stat_t，二者类型不兼容 - 对符号链接行为一致：它读的是目标文件属性（类似
os.Stat），如需链接自身元数据，改用unix.Lstat
UID/GID 字符串转整数时容易漏掉的坑
user.Lookup 或 user.Current() 返回的 Uid 和 Gid 字段是字符串，内容可能是 "1001"，也可能是 "nobody"——POSIX 允许符号名存在，strconv.Atoi 遇到后者会报错。
立即学习“go语言免费学习笔记（深入）”；
- 不要无条件
strconv.Atoi(u.Uid)，先检查是否全数字：unicode.IsDigit(rune(c))或正则^\d+$ - 若需兼容符号名（如
"root"），应调用user.LookupId或user.Lookup反查，而非硬解析 - 容器或 distroless 镜像中
/etc/passwd可能被裁剪，user.LookupId("1001")会返回user: unknown userid，此时只能靠环境变量 fallback
真正麻烦的从来不是“怎么拿 UID”，而是“拿到之后怎么信”。unix.Stat_t 字段虽全，但不同内核头定义下 Uid 类型可能隐式不兼容；user.LookupId 看似方便，却依赖本地 passwd 数据库完整性。生产环境里，这两条路都得配好降级逻辑，不能只写 happy path。
