Windows系统无全局物理内存峰值API，需用GlobalMemoryStatusEx周期采样并自行维护最大值；Linux同理，应读/proc/meminfo计算近似已用内存并记录极值。
Windows下用 GetProcessMemoryInfo 只能查当前值，不是峰值
很多人以为调用 GetProcessMemoryInfo 拿到的 PeakWorkingSetSize 就是系统物理内存峰值，其实它返回的是**当前进程**的峰值工作集——和系统总内存占用完全无关。系统级的物理内存峰值（即自启动以来 RAM 使用最高点），Windows 并不直接暴露这个值。
真正能反映全局物理内存压力的指标，是 PERF_DATA_BLOCK 中的 \Memory\Committed Bytes 或 \Memory\Available MBytes 的历史极值，但 Windows 性能计数器本身不存“历史峰值”，得自己采样记录。
- 若你实际想监控本进程内存使用上限：用
GetProcessMemoryInfo+PeakWorkingSetSize即可 - 若你真需要整个系统的物理内存占用历史最高点：必须周期性读取
GlobalMemoryStatusEx，自己维护一个最大值变量 -
GlobalMemoryStatusEx返回的ullTotalPhys - ullAvailPhys是当前已用物理内存估算值，非精确值（因内核驱动可能保留未上报内存）
Linux下读 /proc/meminfo 无法直接拿到峰值，得靠 /sys/kernel/mm/ 或 cgroup
Linux 内核不维护“系统自启动以来物理内存峰值”这个统计项。/proc/meminfo 里只有当前的 MemTotal、MemAvailable 等瞬时值，没有 MemPeak 这种字段。
真正接近“系统级内存压力峰值”的线索在两个地方：
- 如果系统启用了
cgroup v2且你的进程在 root cgroup 下：读/sys/fs/cgroup/memory.max_usage_in_bytes（注意路径可能为/sys/fs/cgroup/memory.current+ 手动轮询记录） - 更通用的做法是解析
/proc/stat中的pgpgin/pgpgout累计换页量，结合/proc/meminfo推算内存压力趋势，但依然得不到确切峰值 - 部分发行版（如 RHEL/CentOS）带
vmstat -s，但它输出的是启动后累计缺页数，不是内存占用峰值
跨平台统一思路：别依赖 OS 原生峰值 API，自己采样 + 持久化
没有操作系统提供“开机以来物理内存占用最高点”的现成接口。所谓“系统峰值”，本质是一个需长期观测的状态量，必须由应用自己完成三件事：定时采集、比较更新、落盘防丢。
- 采样频率建议 1–5 秒一次；太密影响性能，太疏错过尖峰
- Windows：调用
GlobalMemoryStatusEx，计算ullTotalPhys - ullAvailPhys得当前已用物理内存（单位字节） - Linux：读
/proc/meminfo，提取MemTotal:和MemAvailable:行，差值即近似已用内存（注意单位是 kB，要 ×1024） - 峰值变量必须声明为
std::atomic或加锁，避免多线程写冲突 - 若程序重启后仍需保留历史峰值，得把最大值写入本地文件（如
/var/run/myapp_mem_peak），启动时先读再更新
容易被忽略的关键点：物理内存“已用”不等于“被进程独占”
无论 Windows 还是 Linux，报告的“已用物理内存”都包含 page cache、slab、内核模块映射等不可简单归因于用户进程的部分。尤其在 Linux 上，MemAvailable 已尝试预估可回收量，但 MemTotal - MemAvailable 仍会高估真实压力。
如果你的目的是判断是否该降级或拒绝新请求，与其紧盯“峰值”，不如关注连续多个采样点的 Available 是否低于阈值（例如 Total），并配合 swap 使用率（SwapUsed / SwapTotal）交叉验证。
另外，容器环境（Docker/K8s）中，/proc/meminfo 显示的是宿主机视图，需改读 /sys/fs/cgroup/memory/memory.usage_in_bytes 才反映容器真实内存消耗——这点常被忽略，导致误判。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
