Linux下用stat()获取inode信息最直接：调用stat()填充struct stat，检查返回值为0后读取sb.st_ino；需用有效路径，符号链接默认解析目标，若需自身inode应改用lstat()，且st_ino仅在同st_dev设备内唯一。
Linux下用stat()获取Inode信息最直接
在Linux系统上，stat()是获取文件Inode元数据（如st_ino、st_dev、st_mode等）的标准方式。它不依赖C++标准库抽象，直接封装sys_stat系统调用，返回结构体struct stat，其中st_ino字段就是你要的Inode号。
常见错误是误用std::filesystem::status()——它可能只返回模拟或缓存值，且不暴露st_ino；而std::filesystem::symlink_status()对符号链接会返回链接本身的Inode，不是目标文件的。
- 必须包含
<sys></sys>，不是<filesystem></filesystem> - 传入路径需为C风格字符串（
c_str()），不能是宽字符或空路径 - 若路径是符号链接，默认解析目标；要获取链接自身Inode，改用
lstat() - 注意
st_ino在不同文件系统间不唯一，仅在同st_dev设备内有意义
stat()返回的Inode为什么有时为0？
这不是bug，而是特定场景下的合法行为。典型情况包括：
- 文件系统不支持Inode（如某些FAT32挂载、procfs、sysfs、tmpfs早期版本）——此时
st_ino恒为0 - 路径指向一个未实现
->getattr的伪文件系统对象（例如部分debugfs条目） - 使用了
statx()并显式未请求STATX_INO标志（但stat()不会出现此情况）
验证方法：检查stat()返回值是否为0，并用mount | grep $(df . -P | tail -1 | awk '{print $1}')确认底层FS类型。ext4/xfs/btrfs一定有非零Inode；vfat/ntfs-3g通常为0。
立即学习“C++免费学习笔记（深入）”；
生成Blender Python (bpy)脚本，该脚本使用node_groups API和GeometryNodeTree接口程序化地创建几何节点修改器树，用于参数化3D资产生成。
想绕过glibc走纯系统调用？用syscall(SYS_statx, ...)
statx()是Linux 4.11+引入的增强版接口，比stat()更精细：可指定只读部分字段、区分链接/目标、获取Btime（birth time）、避免自动dereference等。但它不是POSIX标准，跨平台性差。
关键点：
- 需要定义
_GNU_SOURCE并包含<linux></linux>和<sys></sys> - 参数顺序固定：
dirfd（通常AT_FDCWD）、pathname、flags（如AT_SYMLINK_NOFOLLOW）、mask（如STATX_INO | STATX_MTIME）、statxbuf - 返回的
stx_ino字段与stat()的st_ino语义一致，但类型是uint64_t，避免32位截断 - glibc 2.28+已封装
statx()为statx()函数，但旧版本必须手写syscall()
Windows没有Inode，别硬套stat()
Windows NTFS/FAT没有Inode概念，其_stat64i32()等函数返回的st_ino是模拟值（通常为0或文件索引号，但不具唯一性或持久性）。若代码需跨平台：
- 不要把
st_ino当唯一标识符用——改用st_dev + st_ino组合（Linux/macOS有效），或Windows下用GetFileInformationByHandle()的nFileIndexLow/High - CMake中可用
if(CMAKE_SYSTEM_NAME STREQUAL "Linux")条件编译 - std::filesystem::file_id（C++17）在Linux返回
st_dev/st_ino，Windows返回VolumeSerialNumber + FileIndex，是更安全的抽象
Inode本质是Unix-like系统的内部句柄，它的“唯一性”只在单次挂载生命周期内成立；reboot、remount、或同一设备被多次挂载时，相同数字可能指向不同文件。这点常被忽略，尤其在日志去重或inode-based cache场景里。
