Go标准库的os.FileInfo是跨平台抽象，不包含inode字段，因其为Unix特有概念且Windows无对应物；需用os.Lstat()配合syscall.Stat_t类型断言获取st_ino。
Go 里不能靠 os.FileInfo 直接拿到 inode —— 它被抽象掉了，必须穿透到系统调用层才能取到 st_ino。
为什么 os.Stat() 返回的 FileInfo 没有 inode 字段
Go 标准库的 os.FileInfo 是跨平台抽象，只暴露通用字段（Name()、Size()、Mode()、ModTime()）。inode 是 Unix/Linux 特有的底层概念，Windows 没有等价物，所以 Go 故意不把它放进接口。你调 os.Stat("x") 得到的 FileInfo 对象，其底层可能是 *syscall.Stat_t 或 *unix.Stat_t，但你不显式转换就拿不到 st_ino。
- 直接打印
fi.Sys()通常只看到内存地址，不是结构体内容 -
fi.Sys()在 Windows 下返回*syscall.Win32FileAttributeData，压根没 inode 概念 - 即使在 Linux 上，
fi.Sys()类型是interface{}，必须类型断言才能访问字段
用 os.Lstat() + syscall.Stat_t 提取 st_ino
这是最常用、最轻量的方式：不打开文件，只做一次系统调用，拿到完整 struct stat。关键是要用 os.Lstat()（而非 os.Stat()），避免符号链接被自动解析。
- 导入
"syscall"（或更推荐的"golang.org/x/sys/unix"，类型更稳定） - 调用
os.Lstat(path)，检查错误；成功后对fi.Sys()做类型断言：if s, ok := fi.Sys().(*syscall.Stat_t); ok { inode := s.Ino } -
syscall.Stat_t.Ino是uint64，直接用，别转成int防溢出 - 注意：如果路径是损坏的符号链接（dangling symlink），
os.Lstat()仍成功，但s.Ino是链接自身的 inode，不是目标的
用 os.Open() + fstat() 更安全的场景
当你已经打开文件（比如为了读内容），再用 os.Stat() 是冗余且有竞态风险的——文件可能在两次调用之间被删、重命名或替换成另一个文件。fstat() 直接作用于 fd，绕过路径解析，结果稳定。
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
立即学习“go语言免费学习笔记（深入）”；
- 先
f, err := os.Open(path)，再fi, err := f.Stat()—— 这个fi的Sys()同样要断言为*syscall.Stat_t才能取Ino - 或者更底层：用
unix.Fstat(int(f.Fd()), &sb)（需golang.org/x/sys/unix），sb.Ino就是你要的值 - 优势：哪怕文件已被
unlink()，只要f没关，f.Stat()或unix.Fstat()仍返回原始 inode 信息 - 坑点：
f.Fd()在 Windows 不可用；unix.Fstat()只适用于 Unix 系统，编译时需加//go:build unix
判断硬链接存在必须看 st_nlink，不是 st_ino
“这个文件是不是硬链接”本身是个伪命题 —— 硬链接是多个目录项指向同一 inode 的现象，不是文件类型。真正该问的是：“这个 inode 当前被多少个目录项引用？”答案在 st_nlink 字段。
-
st_nlink > 1表示至少还有一个其他硬链接存在（包括它自己） - 用
os.Lstat()+syscall.Stat_t.Nlink获取该值；注意Nlink是uint64，不是布尔值 - 不要用
os.FileMode判断 —— Go 没有ModeHardLink这种标志，ModeSymlink只管软链 - 常见误判：把符号链接（
st_mode & syscall.S_IFLNK != 0）当成硬链接；两者机制完全不同
真正难的不是怎么取 st_ino，而是理解它从来不是全局唯一 ID：同一台机器上，不同挂载点的两个文件可能有相同 st_ino；FAT32/NTFS（WSL）下它可能是伪造的；/proc 和 /sys 里的文件 inode 常为 1。真要唯一标识一个文件，必须同时记录 st_dev 和 st_ino，且仅限当前运行时、同一挂载状态下有效。
