用 stat 系统调用读取 inode 号需调用 stat("/path", &sb)，检查返回值为 0 后访问 sb.st_ino；注意路径有效性、包含 、区分 stat/lstat、配合 st_dev 使用以确保跨设备唯一性。
怎么用 stat 系统调用读取 inode 号
Linux 下获取文件 inode 信息最直接的方式就是调用 stat 系统调用，它把包括 st_ino 在内的所有元数据填进 struct stat 里。stat 不依赖 libc 的封装（比如 fstatat），是内核暴露的底层接口，适合写轻量、确定性高的工具。
常见错误是传错路径或忽略返回值：如果路径不存在、权限不足或路径是悬空符号链接，stat 返回 -1 并设 errno；不检查就直接读 st_ino，会拿到未初始化的垃圾值。
- 用绝对路径或确保当前工作目录正确，相对路径容易因 cwd 变化出错
- 记得包含
<sys></sys>和<unistd.h></unistd.h> -
stat不跟随符号链接——要获取链接文件本身的 inode，用lstat；要获取目标文件的 inode，用stat - 示例：
struct stat sb;<br>if (stat("/tmp/test.txt", &sb) == 0) {<br> printf("inode: %lu\n", sb.st_ino);<br>}
st_ino 在不同文件系统间是否唯一
inode 号只在同一个 mounted 文件系统内有意义。两个不同磁盘、不同挂载点（比如 /home 和 /mnt/usb）上的文件完全可能有相同的 st_ino 值，但它们毫无关系。
这意味着：不能靠 st_ino 做跨设备的文件去重或唯一标识；做文件监控（如 inotify + inode 匹配）时，必须同时记录 st_dev（设备号），组合成 (st_dev, st_ino) 才真正唯一。
-
st_dev是主设备号+次设备号打包的值，用major()/minor()宏可拆解 - NFS 挂载时
st_ino可能被服务器映射重编号，st_dev也常统一为 NFS 伪设备，此时(st_dev, st_ino)仍不跨客户端唯一 - ext4/xfs/btrfs 等本地文件系统中，
st_ino是磁盘上 inode 表的实际槽位索引，重启不重置
为什么 stat 有时比 lstat 慢
表面看只是“跟不跟链接”的差别，实际性能差异来自路径解析阶段：stat 在遇到符号链接时，要一路解析到最终目标，可能触发多次磁盘 I/O（尤其路径深、中间有多个链接）；lstat 到达链接文件自身就停，不访问目标路径。
这在遍历目录树（如实现 find 或备份工具）时特别明显——如果你只关心链接文件自身的元数据（比如谁创建了这个链接、权限如何），无条件用 lstat 更快更安全。
- 某些旧内核或特殊文件系统（如 overlayfs）中，
stat解析失败可能卡住几秒，而lstat几乎总是立即返回 - POSIX 要求
stat对悬空链接返回ENOENT，但部分实现（如某些容器环境）会返回ELOOP，需同时检查两种 errno - 不要为了省一次系统调用，用
stat替代lstat再加readlink—— 多数时候反而更慢且逻辑更脆
C++ 中封装 stat 的几个关键避坑点
用 C++ 封装时，别直接裸写 struct stat 成员访问，容易踩内存对齐、字段大小平台差异的坑（比如 st_ino 在 32 位系统上可能是 unsigned short，64 位上是 unsigned long）。
标准做法是依赖 <sys></sys> 提供的宏和类型定义，而不是硬编码字段类型；同时注意 stat 不是线程安全的（内部可能复用静态缓冲区），但现代 glibc 已修复，不过自定义封装时仍建议每个调用独占 struct stat 实例。
- 用
ino_t接收st_ino，而不是long或uint64_t——它是头文件定义的适配类型 - 避免在类成员里缓存
struct stat后长期持有，文件可能被其他进程修改，st_ino不变但st_mtime等已过期 - 如果需要频繁查多个文件，考虑用
statx（Linux 4.11+）替代，它支持批量查询、指定字段掩码、减少拷贝，但兼容性差，得 fallback 到stat
st_dev 和 st_ino 必须一起看，漏掉设备号几乎必然出错。C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
