如何通过_stat系统调用获取文件系统层Inode号详解？

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

在Linux系统上，C++程序要获取文件的inode号，核心是调用POSIX标准的``头文件中的`stat()`系统调用。

常见错误是传错路径或忽略返回值：如果stat()返回-1，errno会设为具体错误码（比如ENOENT表示文件不存在），直接读st_ino会得到未定义值。

• 路径必须是绝对路径，或相对于当前工作目录的有效相对路径；符号链接默认被解引用——想获取链接文件本身的inode，得用lstat()
• st_ino类型是ino_t，不是int或long，打印时推荐用%lu配合(unsigned long)强转，避免格式错误警告
• 示例片段：

  struct stat sb;<br>if (stat("/path/to/file", &sb) == 0) {<br> printf("inode: %lu\n", (unsigned long)sb.st_ino);<br>}

Windows没有inode概念，GetFileInformationByHandle()能取类似标识但不等价

Windows NTFS/FAT本身不提供POSIX意义上的inode号。虽然GetFileInformationByHandle()返回的dwVolumeSerialNumber和nFileIndexHigh/nFileIndexLow组合起来在同卷内可唯一标识文件，但它不是inode：不能跨重启保证稳定，也不参与硬链接计数，更不被任何Windows API当“inode”对待。

如果你在写跨平台工具（比如同步器、去重工具），别指望这个值能在Linux和Windows间对齐。硬要做映射，只能在运行时按平台分别实现，并明确文档里写清“Windows下为模拟标识，仅限本机本次会话内有效”。

立即学习“C++免费学习笔记（深入）”；

• 调用前需用CreateFile()打开句柄，且权限至少含FILE_READ_ATTRIBUTES
• 返回的nFileIndexHigh和nFileIndexLow需合并为64位整数：((uint64_t)fi.nFileIndexHigh << 32) | fi.nFileIndexLow
• 该值在卷快照、脱机文件、OneDrive等场景下可能变化，不可用于持久化存储

硬链接场景下st_ino相同，但st_nlink才是关键线索

同一个inode可以被多个目录项（硬链接）指向，此时所有链接的stat()结果中st_ino完全一致。单靠inode号无法区分它们——你需要结合st_dev（设备号）确认是否在同一文件系统，再用st_nlink判断该inode当前有多少个硬链接。

容易踩的坑是误以为“不同路径+相同inode = 同一文件”，却没验证st_dev。比如两个挂载点下的文件可能碰巧有相同st_ino，但st_dev不同，实际毫无关系。

• 判断两个路径是否指向同一文件的可靠方式：sb1.st_ino == sb2.st_ino && sb1.st_dev == sb2.st_dev
• st_nlink值反映的是当前已创建的硬链接总数，不是“还有几个链接可用”，它随link()/unlink()实时更新
• 符号链接的st_ino是链接文件自身的inode，不是目标文件的；要用lstat()读链接本身，stat()读目标

性能敏感场景慎用stat()，避免重复调用

每次stat()都是一次系统调用，涉及内核态切换和VFS层查找。如果要在循环里频繁检查成百上千个文件的inode（比如构建文件索引），反复调用stat()会成为明显瓶颈。

优化思路不是“换函数”，而是减少调用次数：批量读取目录内容时，优先用readdir() + d_type快速过滤，再对目标文件集中调用stat()；或者用openat() + fstat()复用目录fd，避免重复路径解析。

• readdir()返回的dirent::d_type字段（若支持）可跳过大部分非普通文件，省去无效stat()
• Linux 5.12+ 支持statx()，能指定只读stx_ino字段，比传统stat()略快，但glibc封装尚未普及，需直接syscall
• 注意：stat()不缓存结果，两次调用之间文件可能被删/重命名，st_ino不变但路径已失效——业务逻辑得处理这种竞态

真正麻烦的从来不是怎么拿到inode号，而是后续怎么用它：硬链接检测要配st_dev，跨平台要放弃严格等价假设，高频访问得压调用次数。这些细节不写进日志、不抛异常，但会在某个凌晨三点让你对着监控曲线发呆。