如何通过stat函数深入解析文件系统Inode元数据？

本文共计924个文字，预计阅读时间需要4分钟。

Linux/macOS 下使用 stat 或 fstat 获取文件信息，不涉及图形解释，无需数字，不超过100字。直接输出结果。

为什么不能靠文件路径直接“查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，而是理解它在什么上下文里有意义 —— 跨文件系统、跨网络、跨命名空间时，它早就不是那个“唯一标识文件”的数字了。