statvfs() 是获取文件系统块大小最轻量可靠的方式，返回内核维护的 f_frsize（逻辑块大小）和 f_bavail（用户可用空间），不提供配额信息；配额需用 quotactl() 或命令行工具；macOS/FreeBSD 应用 statfs() 替代。
Linux 下用 statvfs() 读取文件系统块大小和配额基础信息
直接调用 statvfs() 是获取底层块大小最轻量、最可靠的方式，它不依赖用户权限或额外工具，返回的是内核维护的实时 vfs 层统计。注意：它给出的是「文件系统逻辑块大小」（f_frsize），不是物理扇区大小；f_bsize 是推荐的 I/O 块大小，通常与 f_frsize 相同，但某些文件系统（如 XFS）可能不同。
常见错误是误用 stat() —— 它只返回单个文件的元数据，无法反映整个文件系统容量。另外，statvfs() 不提供用户/组配额（quota）信息，那是另一个机制。
实操建议：
- 传入挂载点路径（如
"/home"），不是任意目录或文件路径；若路径跨挂载点，结果属于其所在文件系统的根挂载点 - 检查返回值是否为 0，失败时
errno可能是ENOTCONN（NFS 断连）、EPERM（极少见，某些安全模块限制） -
f_frsize * f_blocks是总空间字节数，f_frsize * f_bavail是非特权用户可用字节数（已扣除 root 保留块）
#include <sys>
struct statvfs buf;
if (statvfs("/data", &buf) == 0) {
printf("块大小: %ld 字节\n", buf.f_frsize);
printf("总块数: %ld\n", buf.f_blocks);
printf("可用块数（普通用户）: %ld\n", buf.f_bavail);
}</sys>
Linux 下用 quotactl() 和 getfsent() 获取磁盘配额（user/group quota）
statvfs() 给不出谁用了多少、是否超限——这必须走 quota 接口。quotactl() 是内核提供的系统调用封装，但直接用它需要手动构造结构体、处理 quota 文件位置（通常是 /aquota.user 或 /quota.user），门槛高且易出错。更实用的是用 libquota 提供的高层接口，比如 getqfile() + scan_dqblk()，但该库未标准化，发行版支持不一。
实际项目中，推荐用 repquota -n /path 或 quota -u username 的子进程方式解析输出，比手撕 quotactl() 稳定得多。若坚持系统调用级操作，务必确认目标文件系统已启用 quota（mount 输出含 usrquota 或 grpquota）且 quota 文件存在且可读。
关键点：
- 配额信息按 user/group 分开存储，
QCMD(Q_GETQUOTA, USRQUOTA)和QCMD(Q_GETQUOTA, GRPQUOTA)必须分别调用 -
struct dqblk中的dqb_curspace是当前已用字节数（含缓冲未刷盘部分），dqb_bsoftlimit/dqb_bhardlimit是软硬块限制 - 普通用户调用
quotactl()会返回EPERM，必须 root 权限
macOS / FreeBSD 上用 statfs() 替代 statvfs() 并注意字段命名差异
macOS 和 FreeBSD 不支持 statvfs() 的标准 POSIX 字段映射，得用 statfs()。它返回的结构体叫 struct statfs，字段名完全不同：f_bsize 对应推荐 I/O 块大小，f_blocks 是总数据块数，但单位是 f_bsize 而非固定 512 字节；f_bfree 是空闲块数，f_bavail 是非 root 可用块数。
一个典型坑是：macOS 的 statfs() 在 APFS 卷上可能返回不准确的 f_bfree，因为 APFS 使用写时复制和空间共享，内核无法精确预估“立即可用”块数。此时 f_bavail 更可信，但仍可能滞后于实际。
使用建议：
- 不要假设
f_bsize == 4096，APFS 默认是 4096，但可格式化为 64KB；ZFS on macOS（通过 FUSE）则完全另算 - 跨平台代码中，用
#ifdef __APPLE__分支切换到statfs()，并统一用f_bsize * f_bavail算可用字节数 -
statfs()同样不返回 quota 数据；macOS 已弃用传统磁盘配额，改用 Storage Management API（com.apple.storage.corestorage），需 Objective-C/Swift 调用
为什么不能靠 df 命令输出做精确容量判断
df 看起来方便，但它做了多层转换：自动单位换算（K/M/G）、四舍五入、隐藏保留块、甚至受 POSIXLY_CORRECT 环境变量影响字段顺序。更严重的是，df -B1 虽返回字节数，但其底层仍调用 statvfs() 或 statfs()，再经 libc 格式化——中间任何环节被 LD_PRELOAD hook 都可能污染结果。
真正需要精确控制的场景（如备份服务计算预留空间、数据库 WAL 切割阈值），必须自己调用系统 API，而不是解析 df 文本。尤其注意：df 显示的 “Available” 列在 ext4 上默认扣除 5% root reserved space，而 statvfs().f_bavail 已扣除，二者数值一致；但若管理员用 tune2fs -m 0 /dev/sda1 关了保留块，df 和 statvfs() 就会同步变化，无需额外适配。
一句话：脚本里跑 df 可以快速诊断，C++ 里调 df 子进程去取值，等于主动引入解析脆弱性和竞态条件。
配额的 kernel 接口在不同发行版 patch 程度不同，XFS 的 project quota、btrfs 的 subvolume quota 都不被 quotactl() 原生覆盖，得走各自 ioctl；这些细节往往只在 man 2 quotactl 的 BUGS 段落里提一句。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
