Linux/macOS 下必须用 stat() 等系统调用获取 inode，因 inode 是内核分配的独立索引节点，路径与 inode 非一一对应；Windows 无等价概念。需同时比 st_ino 和 st_dev 才能可靠判断同一文件，但 NFS/FUSE 等场景下二者均可能不可靠。
Linux/macOS 下用 stat() 或 fstat() 获取 inode 是唯一可靠方式；Windows 没有等价概念，强行模拟会丢失语义。
为什么不能靠文件路径直接“查inode”？
inode 不是文件名的一部分，而是内核为每个文件分配的独立索引节点。同一路径可能因硬链接、挂载点或 bind mount 指向不同 inode；而同一 inode 也可能被多个路径引用。所以必须通过系统调用让内核返回当前路径解析后实际对应的 inode 号。
-
stat("path", &sb)：传入路径，触发路径解析（包括符号链接跳转），返回最终目标文件的 inode（sb.st_ino） -
lstat("path", &sb)：不跟随符号链接，返回符号链接文件自身的 inode -
fstat(fd, &sb)：已打开文件描述符，绕过路径查找，开销最小，且能避开竞态（如路径被重命名）
stat() 返回的 st_ino 真实吗？要注意什么？
真实，但有边界条件：
- 在 ext4/xfs/btrfs 等本地文件系统上，
st_ino是内核中真实的 64 位 inode 编号 - NFS 挂载时，服务器可能伪造或映射 inode（尤其旧 NFSv3），
st_ino不具备跨主机唯一性 - FUSE 文件系统（如 sshfs、rclone mount）完全由用户态程序控制返回值，
st_ino可能是递增 ID 或哈希，无物理意义 - 容器环境（如 Docker overlay2）中，宿主机看到的是 lower/upper/work 目录下的真实 inode，而容器内看到的是联合挂载后的逻辑 inode，二者不同
C++ 中调用 stat() 的最小安全写法
别用 <filesystem>（C++17 std::filesystem::status() 不暴露 inode）；直接封装 stat() 更可控：
立即学习“C++免费学习笔记（深入）”；
#include <sys/stat.h>
#include <string>
std::uint64_t get_inode(const std::string& path) {
struct stat sb;
if (stat(path.c_str(), &sb) != 0) return 0; // 失败返回 0（inode 不可能是 0）
return static_cast<std::uint64_t>(sb.st_ino);
}
- 必须检查返回值，
stat()失败时st_ino内容未定义 -
st_ino类型是ino_t，大小平台相关（32 位或 64 位），强制转成uint64_t避免截断 - 不要用
std::filesystem::file_size()或last_write_time()替代 —— 它们内部也可能调用stat()，但不提供st_ino
想对比两个路径是否指向同一文件？只比 inode 不够
仅比较 st_ino + st_dev（设备号）才构成“同一文件”的充分条件：
- 不同分区（
st_dev不同）即使st_ino相同，也绝不是同一个文件 - 同一设备上
st_ino == st_ino && st_dev == st_dev才表示硬链接或同一 open 实例 - 注意：NFS 或 FUSE 下
st_dev可能恒为 0 或不可靠，此时需 fallback 到内容哈希或open()/ioctl(FICLONE)等机制
真正难的不是拿到 inode，而是理解它在什么上下文里有意义 —— 跨文件系统、跨网络、跨命名空间时，它早就不是那个“唯一标识文件”的数字了。
