Windows下获取进程内存占用排名需先枚举所有进程并逐个调用GetProcessMemoryInfo获取内存数据，再自行排序，因系统无直接提供排名的API。
Windows下用 GetProcessMemoryInfo 获取单个进程内存使用量
直接获取“排名”不存在系统级 API，必须先拿到所有进程的内存数据再排序。核心是 GetProcessMemoryInfo，但它只作用于单个 HANDLE，不能直接查别人——得先用 CreateToolhelp32Snapshot 枚举所有进程，再对每个有效句柄调用它。
常见错误是忽略权限：打开某些系统进程（如 svchost.exe）的 PROCESS_QUERY_INFORMATION 权限失败，导致 GetProcessMemoryInfo 返回 FALSE 且 GetLastError() 是 ERROR_ACCESS_DENIED。建议用 OpenProcess 时加上 PROCESS_QUERY_LIMITED_INFORMATION（Win8+）或降级处理——跳过无权限进程，别让整个枚举崩掉。
- 记得调用
GlobalMemoryStatusEx检查当前物理内存总量，否则 RSS 值缺乏参照系 -
PROCESS_MEMORY_COUNTERS_EX比基础结构体多返回PageFaultCount和PrivateUsage，推荐优先用它 - 64位程序读取 32位进程时，
SIZE_T字段不会截断，但需确保结构体用#pragma pack(push, 8)对齐
Linux下通过 /proc/[pid]/statm 和 /proc/[pid]/status 提取 RSS
Linux 没有统一 API，靠读取 /proc 文件系统。关键字段是 /proc/[pid]/statm 的第二列（RSS 页面数），乘以 getpagesize() 得字节数；更准的是 /proc/[pid]/status 里 rss: 行，单位是 KB。
容易踩的坑是进程已退出但 PID 未被回收（/proc/[pid] 目录还在），读 statm 会成功但内容为 0；或者权限不足（容器内非 root 进程看不到其他容器的 /proc）。建议先 kill(pid, 0) 检查进程是否存在，再读文件。
立即学习“C++免费学习笔记（深入）”；
- 避免用
ps aux --sort=-%mem解析文本——字段位置随 locale 变化，%MEM列可能被截断或换行 - 遍历
/proc下所有数字目录比libprocps更轻量，但要注意/proc/self和线程/proc/[pid]/task/[tid]目录干扰 -
statm的 RSS 包含共享库内存，若要纯私有内存，看/proc/[pid]/smaps的Private_Dirty:总和（开销大，慎用）
跨平台排序逻辑必须自己实现
没有操作系统提供“按内存占用排序的进程列表”，所有“排名”都是客户端计算结果。关键不是怎么取单个值，而是怎么组织数据流：枚举 → 过滤（排除自身、无效句柄、无权限）→ 获取 RSS → 存入 std::vector<std::pair<pid_t, size_t>> → std::sort。
性能上，Linux 下读几千个 /proc/[pid]/statm 文件比 Windows 下开几千个 OpenProcess + GetProcessMemoryInfo 快得多（前者是内存映射，后者涉及内核对象查找）。但 Windows 上若用 EnumProcesses 替代 CreateToolhelp32Snapshot，能减少约 30% 时间——不过它不返回进程名，得额外调用 GetModuleBaseName。
- 排序时注意 RSS 为 0 的进程（僵尸/挂起）应排最后，而非最前
- 同一 RSS 值的进程，按 PID 升序作为次级排序键，保证结果稳定
- 输出“第 N 名”时，N 是从 1 开始的索引，别用
std::distance算迭代器偏移搞错
真实场景中“内存占用”的定义差异极大
用户说的“内存占用”可能是 RSS、VSS、Working Set、Private Bytes 或 PSS——不同指标含义完全不同。例如 Chrome 多进程架构下，单个渲染进程 RSS 小，但所有子进程 RSS 总和远超主进程；而 PSS（Proportional Set Size）会把共享内存按进程数均摊，更适合总览。
开发时必须明确需求方要什么：任务管理器显示的是 Working Set（Windows）或 RSS（Linux top 默认），但 OOM killer 触发依据是 oom_score_adj 加权后的内存压力，和单纯 RSS 无关。别默认用 RSS 当唯一标准。
- Windows 上
PROCESS_MEMORY_COUNTERS_EX.PrivateUsage≈ Linux 的 PSS，但非完全等价 - Docker 容器内应用看到的
/proc/meminfo是宿主机全局值，需结合cgroup的memory.usage_in_bytes才准确 - Java 进程的堆外内存（Netty direct buffer、JNA）不计入 JVM
Runtime.totalMemory()，但算在 RSS 里
排名本身只是表象，背后指标选错，结果就失去意义。尤其在容器或虚拟化环境里，RSS 差异可能来自内存回收策略而非真实负载。
