Linux的VmHWM是进程生命周期内RSS最高值，精确反映物理内存真实峰值；Windows的PeakWorkingSetSize受系统策略影响，非严格单调，需自行维护运行时最大WorkingSetSize。
Linux 下用 /proc/pid/status 读取 VmHWM 是最准的峰值指标
Windows 的 GetProcessMemoryInfo 返回的 PeakWorkingSetSize 实际是工作集峰值，不等于物理内存真实峰值；Linux 的 VmHWM（High Water Mark）才是进程生命周期内 RSS 达到过的最高字节数，对应物理内存实际占用峰值，监控意义最直接。
实操时注意：/proc/self/status 每次读取都是瞬时快照，但 VmHWM 是只增不减的累计值，只要进程没重启，它就始终保留历史最高值。所以适合在程序退出前或定时采样时读取。
- 必须以文本方式打开并逐行扫描，不能依赖固定偏移 ——
VmHWM行格式为VmHWM: 123456 kB，冒号后有空格，单位固定为kB - 推荐用
std::ifstream配合std::string::find解析，避免scanf类函数因格式微变崩溃 - 若在容器中运行，
/proc/pid/status仍有效，但需确认挂载了procfs（绝大多数容器默认启用）
Windows 上用 GetProcessMemoryInfo 时别混淆 PeakWorkingSetSize 和 PeakPagefileUsage
PeakWorkingSetSize 是进程曾拥有的最大工作集大小（即被锁定在物理内存中的页数），但它受系统策略影响大：比如其他进程内存压力高时，系统可能主动 trim 掉你的工作集，导致该值偏低甚至“回退”——它不是严格单调递增的。
相比之下，PeakPagefileUsage 是进程生命周期内提交到页文件的最大虚拟内存总量，和物理内存无直接关系，不能用于监控真实内存峰值。
- 真正能近似替代
VmHWM的是PERFORMANCE_INFORMATION中的CommitTotal减CommitLimit？不，那是全系统级，粒度太粗 - 更可行的做法：在关键路径（如大图加载、模型推理后）主动调用
GetProcessMemoryInfo，记录WorkingSetSize的运行时最大值，自己维护一个单调递增变量 - 记得链接
psapi.lib，且PROCESS_QUERY_INFORMATION权限必须开启（通常默认有）
跨平台封装时，别直接暴露 VmHWM 或 PeakWorkingSetSize 作为统一接口返回值
两者语义不同：Linux 的 VmHWM 是精确、不可逆、内核维护的物理内存峰值；Windows 的 PeakWorkingSetSize 是用户态采样+系统干预的结果，存在抖动和滞后。强行统一命名会误导调用方以为行为一致。
建议分层设计：
- 底层接口按平台提供原生值：
get_linux_vmhwm_kb()/get_windows_peak_workingset_bytes() - 上层业务逻辑根据场景选：做资源超限告警用 Linux 值；做 Windows 客户端内存趋势分析，用自己维护的运行时最大
WorkingSetSize - 如果必须统一返回，文档里明确写死：“该值在 Linux 下为
VmHWM，Windows 下为当前WorkingSetSize的历史最大采样值，非内核级峰值”
高频轮询 /proc/self/status 会导致 stat 系统调用开销明显上升
每秒读一次基本无感，但若在性能敏感循环里每毫秒读一次，open + read + close 的开销会从纳秒级升至微秒级，还可能触发 VFS 层锁竞争。这不是理论风险，我们在一个实时音视频转码进程中实测过，轮询频率 >100Hz 后 CPU 占用率额外增加 3%~5%。
- 改用
proc/sys/kernel/mm/ksm类接口？不行，KSM 相关参数不暴露进程级 RSS 峰值 - 更轻量方案：用
mincore()+mmap手动统计驻留页？太重，且无法反映历史峰值 - 务实解法：把轮询改为事件驱动 —— 在已知内存暴涨点（如
new大数组、cv::Mat::create、torch::empty）之后立即采样一次，比守株待兔高效得多
真正难的从来不是读哪个字段，而是想清楚你要回答的问题：是“这个进程历史上最多吃了多少物理内存”，还是“它现在是不是快把机器吃垮了”。前者靠 VmHWM，后者得看全系统可用内存 + 其他进程行为。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
