Linux下用stat()获取Inode信息最直接：调用stat()填充struct stat，从中读取st_ino字段；必须检查返回值是否为0，路径需有效，跨文件系统唯一性需结合st_dev判断。
Linux下用stat()获取Inode信息最直接
在Linux平台，stat()系统调用是读取文件Inode元数据的标准途径，C++程序通过封装在<sys/stat.h>里的stat()函数即可调用。它把Inode中核心字段（如st_ino、st_mode、st_uid、st_mtime等）一次性填入struct stat结构体，无需手动解析磁盘布局。
注意：这不是“跨平台方案”，Windows没有Inode概念，stat()在MSVC或MinGW下返回的是模拟值（如st_ino恒为0），生产环境务必检查errno并做平台判断。
-
stat()不跟随符号链接——想获取链接文件本身的Inode，用lstat() - 路径过长或权限不足时，
stat()返回-1，errno设为ENAMETOOLONG或EACCES，必须检查而非忽略 - 对NFS或某些FUSE文件系统，
st_ino可能不唯一，不能用于跨挂载点的文件去重
st_ino不是绝对唯一ID，别拿它当文件指纹
st_ino只是Inode编号，在单个文件系统内有意义；同一台机器上不同挂载点（比如/home和/mnt/usb）的st_ino完全可能重复。更隐蔽的问题是：ext4默认启用inode64挂载选项后，st_ino可能是64位值，但老代码若用unsigned int接收会截断——务必用ino_t类型声明变量。
- 比较两个路径是否指向同一文件，应同时比对
st_dev（设备号）和st_ino，缺一不可 -
std::filesystem::status()（C++17）底层也调用stat()，但它不暴露st_ino，需回退到POSIX接口 - 容器或chroot环境下，
st_dev可能被虚拟化，stat()返回的设备号与宿主机不一致
想绕过VFS缓存读原始Inode？别试了
有人想跳过内核VFS层，用open("/dev/sda1", O_RDONLY)再lseek到Inode表位置手工解析——这不仅需要root权限、文件系统知识（ext4的Inode表起始块、组描述符偏移），还极易因内核版本升级或日志模式（journaled vs. ordered）导致结构偏移变化。实际项目中，这种做法99%会导致段错误或误读。
立即学习“C++免费学习笔记（深入）”；
- 所有稳定接口都经由
stat()或fstat()（对已打开fd）提供，这是唯一受保证的途径 - 若需更高频访问（如监控大量文件），可用
inotify监听事件，避免轮询stat()，但依然无法绕过VFS - 调试时想看原始Inode内容，用
debugfs -R "stat <inode_num>" /dev/sda1，但这纯属离线分析，不能嵌入程序
glibc的stat()其实做了不少隐藏动作
你以为stat("foo.txt", &sb)就是一条系统调用？glibc内部会先查AT_FDCWD目录的dentry缓存，再尝试fast path路径解析；如果路径含..或符号链接，还会触发多次getcwd()和readlink()调用。strace可验证：stat()偶尔伴随openat(AT_FDCWD, "...", O_RDONLY|O_NOFOLLOW|O_CLOEXEC)出现——那是glibc在处理相对路径歧义。
- 高并发场景下，频繁
stat()小文件可能成为瓶颈，考虑用statx()（Linux 4.11+）按需请求字段，减少内核拷贝 -
statx()需定义_GNU_SOURCE并包含<linux/stat.h>，返回结构体更大，但支持精确控制是否跟随链接、是否读取btime等 - Android NDK或musl libc可能未实现
statx()，上线前务必验证目标环境
真正难的从来不是拿到st_ino，而是理解它在什么上下文里才可靠——设备号、挂载命名空间、文件系统实现细节，这些才是线上出问题时翻车的地方。
