GetProcessMemoryInfo返回的WorkingSetSize不等于任务管理器“内存使用量”，因其包含共享页，而任务管理器显示的是PrivateWorkingSetSize（独占物理内存）；需用PROCESS_MEMORY_COUNTERS_EX结构及对应大小才能获取该值。
GetProcessMemoryInfo 为什么返回的 WorkingSetSize 不等于任务管理器显示的“内存使用量”
因为 WorkingSetSize 表示进程当前驻留在物理内存中的页数（含共享页），而任务管理器默认显示的是 PrivateWorkingSetSize——即该进程独占、不可被其他进程共享的物理内存。两者差值可能很大，尤其在加载了大量系统 DLL 的进程中。
实操建议：
- 必须用
PROCESS_QUERY_INFORMATION和PROCESS_VM_READ权限打开进程句柄，否则GetProcessMemoryInfo失败并返回ERROR_ACCESS_DENIED - 调用前需链接
psapi.lib，并在源文件中#include <psapi.h> - 结构体
PROCESS_MEMORY_COUNTERS必须初始化为 0，并正确设置cb成员，否则 Windows 可能拒绝填充数据
如何正确获取当前进程的 PrivateWorkingSetSize（真实物理内存占用）
这是最贴近用户感知的“内存用量”，也是性能监控常用指标。关键点在于：结构体大小必须设为 sizeof(PROCESS_MEMORY_COUNTERS_EX)，且使用 GetProcessMemoryInfo 的扩展版本需要 Windows 8+，但实际兼容性良好。
简短示例：
立即学习“C++免费学习笔记（深入）”；
PROCESS_MEMORY_COUNTERS_EX pmc = {0};
pmc.cb = sizeof(pmc);
if (GetProcessMemoryInfo(GetCurrentProcess(), (PPROCESS_MEMORY_COUNTERS)&pmc, sizeof(pmc))) {
SIZE_T privateWs = pmc.PrivateWorkingSetSize; // 单位：字节
}注意：PrivateWorkingSetSize 是 PROCESS_MEMORY_COUNTERS_EX 特有字段，PROCESS_MEMORY_COUNTERS 里没有。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
跨平台替代方案：Linux/macOS 下怎么拿到类似数值
Windows 的 GetProcessMemoryInfo 没有直接等价 API，但可通过读取 /proc/self/statm（Linux）或 task_info（macOS）逼近。不过要注意：这些值受内核调度和内存压缩影响，与 Windows 的 PrivateWorkingSetSize 并非严格可比。
Linux 示例（C++）：
std::ifstream f("/proc/self/statm");
if (f.is_open()) {
long size, resident;
f >> size >> resident; // resident * getpagesize() ≈ 物理页数
}常见坑：
-
/proc/self/statm中第二列是 RSS（Resident Set Size），但它包含共享库的物理页，不是私有内存 - macOS 的
task_info需要TASK_BASIC_INFO_64，且返回的phys_footprint才接近PrivateWorkingSetSize
为什么 GetProcessMemoryInfo 在某些机器上总返回 0 或失败
多数情况不是代码问题，而是权限或环境限制：
- 以普通用户运行时，对某些系统进程（如
svchost.exe）调用会失败，即使自己是管理员，也需显式启用SeDebugPrivilege - 32 位程序在 64 位 Windows 上调用时，若未正确处理指针宽度（比如误用
DWORD接收SIZE_T），会导致高位截断、数值异常 - 某些安全软件（如火绒、卡巴斯基）会 hook 或拦截
GetProcessMemoryInfo，导致返回 0 或ERROR_INVALID_PARAMETER
调试时先用 GetLastError() 确认错误码，比盲目改代码更有效。真正难处理的，是那些不报错但返回值长期不动的场景——大概率是内核做了延迟更新或统计被抑制了。
