物理内存峰值需手动记录历史最大值，因系统不持久保存该指标；Windows用PROCESS_MEMORY_COUNTERS_EX::PeakWorkingSetSize（Vista+）或自行采样更新，Linux需解析/proc/self/status的VmRSS并本地追踪，跨平台推荐原子变量定期采样。
GetProcessMemoryInfo 和 /proc/self/status 都不直接提供“物理内存峰值”，必须靠你自己记录历史最大值——系统内核不持久保存该指标，只暴露当前瞬时值。
Windows 下用 GetProcessMemoryInfo + 手动追踪峰值
GetProcessMemoryInfo 返回的 PROCESS_MEMORY_COUNTERS::WorkingSetSize 是当前工作集（即驻留物理内存），但它**没有 PeakWorkingSetSize 字段**；PROCESS_MEMORY_COUNTERS_EX 才有 PeakWorkingSetSize，但仅当使用 GetProcessMemoryInfo 传入该扩展结构体时才有效，且需确保结构体 cb 正确设为 sizeof(PROCESS_MEMORY_COUNTERS_EX)。
- 必须包含
<psapi.h></psapi.h>并链接psapi.lib，否则链接失败 -
PROCESS_MEMORY_COUNTERS_EX是 Windows Vista+ 新增，XP 不支持；若需兼容旧系统，得降级为手动记录 - 即使调用成功，
PeakWorkingSetSize只反映自进程启动以来的最高工作集值，不重置、不可清零，也不能区分是否已被系统回收后又涨回来 - 建议在主线程初始化时读一次作为基线，之后每秒采样并更新本地变量：
peak_rss = std::max(peak_rss, pmc.WorkingSetSize)
Linux 下读 /proc/self/status 没有 PeakRSS，只能自己记
/proc/self/status 的 VmRSS 行只给当前值，/proc/self/statm 第二列也一样；内核不维护进程级 RSS 峰值。你无法通过单次系统调用拿到它。
- 不要试图解析
/proc/self/stat或/proc/[pid]/stat——那里面只有启动时间、调度统计，没有内存峰值 -
/proc/self/status中的MMUPageSize、RssAnon等字段是细节补充，不解决峰值问题 - 若需高精度（比如毫秒级捕获尖峰），别依赖频繁 fopen/fgets；可 mmap
/proc/self/status后用 strstr 定位"VmRSS:"，减少 I/O 开销 - 多线程环境注意：峰值变量需用
std::atomic<size_t></size_t>或加锁保护，避免竞态导致漏记
跨平台峰值监控的实用建议
统一用“采样 + 本地 max 记录”最可靠，比依赖系统接口更可控：
- 初始化一个全局
std::atomic<size_t> g_peak_rss_kb{0}</size_t>，所有采样点都用fetch_max更新 - 采样间隔建议 ≥100ms：太密无意义（内核按页管理，变化本就不连续），还拖慢程序
- 不要混用单位：Windows 返回字节，Linux
VmRSS是 KB，统一转成 KB 或 MB 再比较 - 如果程序 fork 出子进程，子进程的峰值需单独统计——父进程的
PeakWorkingSetSize不继承、不共享
真正容易被忽略的是：峰值一旦达到，就不会自动回落；你得在进程生命周期内持续持有这个变量，并确保它不被优化掉（例如放在静态变量或全局对象里，而非栈上临时变量）。
Handsfree Windows Control
下载
通过 handsfree-windows CLI控制 Windows 本机应用 (UIA) 和浏览器 (Playwright) 的引导技能，用于自动化或测试桌面应用。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
