正确用法是调用statvfs()传入绝对挂载点路径，用f_frsize×f_blocks得总字节数、f_frsize×f_bavail得普通用户可用字节数；f_bsize仅作I/O优化参考，非容量计算依据。
statvfs() 获取文件系统块大小和可用空间的正确用法
Linux/macOS 下直接读取底层块大小不能靠 stat()，它只返回文件自身信息；必须用 statvfs() 系统调用。它返回的是文件系统级别的元数据，包括逻辑块大小（f_frsize）、总块数（f_blocks）、可用块数（f_bavail）等。
关键点：不要用 f_bsize 当“物理块大小”——它是 I/O 优化建议值，可能被内核动态调整；真正用于容量计算的是 f_frsize（fundamental filesystem block size）。
常见错误：传入相对路径或未挂载路径导致 statvfs() 返回 -1 并设 errno = ENOENT；务必用绝对路径且确保路径位于目标挂载点内。
-
f_frsize * f_blocks= 文件系统总字节数（含保留空间） -
f_frsize * f_bavail= 普通用户可用字节数（已扣除 root 保留块） - 若需 root 视角的可用空间，用
f_frsize * f_bfree（但注意普通进程通常无权访问）
getrlimit() 和 quotactl() 不适用于普通用户获取磁盘配额
很多教程误把 getrlimit(RLIMIT_FSIZE) 当作磁盘配额——它只是进程级单文件大小软/硬限制，和文件系统配额（user/group quota）完全无关。真正的配额信息需要 quotactl() 系统调用，但它要求 CAP_SYS_ADMIN 或 root 权限，普通用户调用会直接失败并返回 EPERM。
立即学习“C++免费学习笔记（深入）”；
实际场景中，非 root 用户想知道自己在某分区的配额，唯一可行方式是解析 quota 命令输出（如 quota -u $USER -p /path），或读取 /proc/mounts 确认对应挂载是否启用配额（含 或 <code>grpquota 标志），再尝试访问 /aquota.user（需权限）。
- 检查配额是否启用：
mount | grep " /mnt/data "，看输出是否含usrquota -
quotactl(QCMD(Q_GETQUOTA, ...))在非特权进程里必然失败，别白费力气封装异常处理 - 配额统计单位是 1KB 块（不是字节），
dqb_curblocks字段值需 ×1024 才得当前占用字节数
跨平台兼容性：Windows 上没有 statvfs()，改用 GetDiskFreeSpaceEx()
Windows 不提供 POSIX 的 statvfs()，必须用 Win32 API：GetDiskFreeSpaceEx()。它返回三个 ULARGE_INTEGER：总空间、空闲空间、用户可用空间（考虑配额后）。注意：它不暴露“块大小”，因为 NTFS 的簇（cluster）大小需另查 GetDiskFreeSpace() 的 lpBytesPerSector 和 lpSectorsPerCluster 相乘得出。
容易踩的坑：传入路径末尾带反斜杠（如 "C:\\"）会导致函数失败；必须是根目录格式（"C:\"）或挂载点路径（"D:\data"），且路径必须存在。
-
GetDiskFreeSpace()返回的lpBytesPerSector是扇区大小（通常 512 或 4096），lpSectorsPerCluster是每簇扇区数，二者相乘才是 NTFS 实际分配单元（即“块大小”） -
GetDiskFreeSpaceEx()的lpFreeBytesAvailable已自动扣减配额限制，比 Linux 的f_bavail更贴近用户真实可用值 - MinGW/MSVC 均支持，但需链接
kernel32.lib，CMake 中加target_link_libraries(myapp PRIVATE kernel32)
为什么 df -B1 输出和 statvfs() 计算结果有微小差异？
差异通常在几 KB 到几 MB 级别，主因是 df 默认使用 statfs()（glibc 封装），而 statfs() 和 statvfs() 对某些字段（如 f_files、f_ffree）的语义定义不同；更关键的是，XFS/ext4 等现代文件系统会为日志、预留 inode 区域等保留少量空间，这部分不计入 f_bavail，但 df 可能按不同策略汇总。
调试建议：用 sudo dumpe2fs -h /dev/sda1 2>/dev/null | grep -E "(Block count|Free blocks|Reserved block count)"（ext*）或 xfs_info /mount/point（XFS）对比原始设备级数据，确认是否为内核抽象层导致的统计口径差异。
- 永远以
f_frsize * f_bavail为准做程序内空间判断，而非依赖df输出做自动化决策 - 若需高精度配额感知，不要仅靠系统调用——应结合
quotaCLI 工具 + 缓存机制，避免频繁 fork - 容器环境（如 Docker overlay2）下，
statvfs()返回的是宿主机文件系统数据，无法反映容器层限制，此时必须查 cgroup v2 的io.max或memory.max（若挂载了 io controller）
