Linux下通过读取/proc/self/status中的VmHWM字段可获取进程自启动以来的物理内存RSS峰值（单位KB），该值由内核维护、单调递增，最轻量可靠；macOS需用task_info()采样phys_footprint自行比较得峰值，Windows则调用GetProcessMemoryInfo()获取PeakWorkingSetSize。
Linux 下用 /proc/self/status 读取 VmHWM
Linux 内核会在 /proc/self/status 中记录当前进程的堆内存历史最高使用量（即“高水位”，High Water Mark），对应字段是 VmHWM，单位为 KB。这是最轻量、无需额外依赖的方式。
注意：VmHWM 是整个进程的物理内存驻留集（RSS）峰值，不单指堆，但对大多数纯堆分配场景（如大量 new/malloc、无大块 mmap 或共享库动态加载）来说，它能较好反映堆峰值——因为堆扩张通常是 RSS 增长的主因。
实操建议：
- 用
std::ifstream打开/proc/self/status，逐行读取，匹配以VmHWM:开头的行 - 用
std::stoi或std::strtol提取数值，别直接sscanf忽略单位（后面有空格和KB） - 该文件每行末尾含换行符，匹配时建议用
line.find("VmHWM:") == 0而非==全字符串比较 - 若程序被
setuid或在容器中受限，/proc/self/status可能不可读（返回空或权限错误），需加if (!file.is_open())判断
macOS 下只能靠 task_info + mach_task_basic_info
macOS 没有 /proc，也没有等价的 VmHWM。最接近的是 task_info 返回的 phys_footprint（实际物理内存占用），但它不是峰值，而是当前值；且该字段仅在较新系统（macOS 10.9+）中可用，旧版只能拿到 resident_size（粗略 RSS）。
立即学习“C++免费学习笔记（深入）”；
没有真正的“历史峰值”接口。如果你必须估算堆高峰，可行路径是：
- 在关键分配点（如循环末尾、阶段性完成处）主动调用
task_info(mach_task_self(), TASK_BASIC_INFO, ...)，自己维护一个最大值变量 - 注意：每次调用
task_info是系统调用，频繁轮询会影响性能，不建议在 tight loop 里每轮都查 -
mach_task_basic_info结构体中virtual_size和resident_size都是瞬时值，无法回溯历史；别误以为virtual_size是堆峰值（它包含所有 mmap 区域，远大于堆）
Windows 下用 GetProcessMemoryInfo 查 PeakWorkingSetSize
Windows 提供 PROCESS_MEMORY_COUNTERS，其中 PeakWorkingSetSize 字段表示进程工作集（物理内存驻留）的历史最大值，单位字节。和 Linux 的 VmHWM 类似，它也不是纯堆指标，但在常规堆主导场景下可用。
实操要点：
- 需
#include <psapi.h>并链接psapi.lib（VS 默认不自动链接，容易报LNK2019） - 调用前确保有
PROCESS_QUERY_INFORMATION权限；沙盒环境或低完整性进程可能失败，需检查GetLastError() -
PeakWorkingSetSize不会自动重置，从进程启动开始累计；如果想测某段代码的局部峰值，得在前后两次调用并做差值（但要注意：其他线程或系统活动也会推高该值）
跨平台方案为何不推荐 malloc hook 或 LD_PRELOAD
有人想通过拦截 malloc/free 统计累计分配峰值，这条路理论上可行，但落地极难：
- C++ 的
operator new重载只覆盖new表达式，不捕获malloc、std::vector内部调用、第三方库分配，漏检严重 - Linux 的
__malloc_hook在 glibc 2.34+ 已废弃，且多线程下不安全；LD_PRELOADhookmalloc会干扰调试器和 sanitizer（如 ASan） - 即使全量 hook 成功，你也只能知道“申请了多少”，不知道“操作系统实际给了多少物理页”——因为
malloc通常预分配大块再切分，sbrk/mmap调用频次远低于malloc调用频次，真正决定物理内存峰值的是后者
所以除非你控制全部代码链且只关心逻辑分配量（而非真实内存压力），否则别碰运行时 hook。
真实场景里，VmHWM（Linux）、PeakWorkingSetSize（Windows）是唯一实用的“物理内存峰值”信号。它们不完美，但够用——前提是理解它们统计的是什么，以及为什么不能直接等同于“堆分配峰值”。
