windows 通过 getperformanceinfo 的 committotal/commitlimit 计算页面交换文件使用率，linux 通过 /proc/meminfo 的 swaptotal 和 swapfree 计算；二者语义不等价，需分平台处理且注意单位、零值和瞬时性。
Windows 下用 GetPerformanceInfo 获取页面交换文件使用率
Windows 没有直接返回“页面交换文件使用率”的 API，但 GetPerformanceInfo 能拿到当前提交的内存总量（CommitTotal）和系统允许的最大提交量（CommitLimit），二者相除就是页面交换文件（即分页文件）的当前使用率——因为 Windows 的提交内存由物理内存 + 分页文件共同支撑，这个比值本质上反映了分页文件被“透支调用”的程度。
注意：该函数需链接 Psapi.lib，且返回的是整个系统的提交内存状态，不是单个进程的。
实操建议：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 调用前确保
PERFORMANCE_INFORMATION结构体大小正确初始化：pi.cb = sizeof(PERFORMANCE_INFORMATION) -
CommitTotal和CommitLimit单位是页面数（通常为 4KB），不要误当字节用 - 若
CommitLimit == 0（极少见），说明系统未启用分页文件，此时使用率无意义，应跳过计算 - 结果建议用
double(CommitTotal) / CommitLimit计算，避免整数截断
Linux 下读取 /proc/meminfo 中的 SwapUsed 和 SwapTotal
Linux 不提供“页面交换文件使用率”的统一指标，但可通过解析 /proc/meminfo 得到 SwapTotal: 和 SwapFree: 两行，相减得已用交换空间，再做除法即可。注意：这里的 SwapTotal 是所有激活 swap 设备（文件或分区）的总和，不是单个文件。
常见错误现象：直接读 /proc/swaps 只能看到每个 swap 设备的状态，但不包含“已用/总量”汇总；而 /sys/block/*/swapon 等路径不暴露用量数据。
实操建议：
- 逐行读取
/proc/meminfo，匹配以SwapTotal:和SwapFree:开头的行，提取后跟的数字（单位 KB） - 某些内核配置下（如禁用 swap），
SwapTotal可能为 0，此时分母为 0，必须提前判断并返回 0 或 -1 表示不可用 - 不要依赖
MemAvailable或Committed_AS计算，它们反映的是不同维度的内存压力
C++ 跨平台封装时为什么不能用 sysconf(_SC_AVPHYS_PAGES)
sysconf(_SC_AVPHYS_PAGES) 返回的是可用物理页数，和交换文件完全无关；_SC_PHYS_PAGES 是总物理页数；这两个值对计算交换使用率毫无帮助。有人误以为“可用物理页越少，swap 就用得越多”，但 Linux 的 swap 使用策略（如 swappiness）、页面回收机制、mmap 映射类型等都会打破这种线性假设。
更关键的是：这些 sysconf 值在 Windows 上根本不存在，跨平台代码若混用会编译失败或行为未定义。
实操建议：
- 跨平台项目应严格按系统分支处理：Windows 走
GetPerformanceInfo，Linux 走/proc/meminfo - 避免封装成统一接口名（如
get_swap_usage()）却在内部偷偷返回物理内存占比，这会让调用方误解指标含义 - 若需抽象，至少在文档中明确标注：该函数返回的是“系统级提交内存占用率（Windows）”或“活跃 swap 占用率（Linux）”，二者语义并不等价
获取结果后容易被忽略的精度与时机问题
这个数值是瞬时快照，且受系统调度影响较大。例如：某个进程刚触发 major fault，大量 page-in 后立刻读取，可能看到 swap usage 短暂飙升；而后台 kswapd 正在回收页面时，读数又可能偏低。
实操建议：
- 单次采样意义有限，监控场景建议至少间隔 1s 以上连续采样 3–5 次，取中位数而非平均值（防毛刺）
- Windows 的
CommitTotal包含所有进程的提交请求，包括 reserve 未 commit 的虚拟地址空间，所以数值可能高于实际物理+swap 占用 - Linux 下若启用了 zram 或 zswap，
SwapTotal不体现压缩后的真实存储消耗，但SwapUsed仍按解压后大小统计——这意味着显示使用率 90% 时，底层闪存可能只占 30%
别指望一次读取就得到“精确负载”，重点是理解它反映的是哪一层的资源压力，以及你的业务是否真的关心这一层。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
