直接打开活动监视器→内存标签页→按“内存”列排序可快速定位高占用应用；关注code helper、docker desktop等进程，结合“被压缩的内存”“虚拟内存”判断泄漏；典型表现为内存持续上涨、关闭操作后不回落、重启归零后复升；辅以top、ps、vmmap等命令验证；若用户进程正常而压力仍高，需排查kext等内核级泄漏。
直接打开活动监视器，切换到“内存”标签页，按“内存”列排序就能看到哪个应用占得多。但真正影响体验的往往不是瞬时数值，而是内存是否持续上涨、系统是否开始压缩或交换——这些才是泄漏的关键信号。
快速定位高占用应用
启动活动监视器后，点击顶部“内存”列标题一次，列表会按当前物理内存占用从高到低排列。重点关注名称中含 Code Helper（VS Code 渲染进程）、Docker Desktop、node、python、postgres、qemu-system 等关键词的进程。右键表头勾选“被压缩的内存”和“虚拟内存”，若某进程“被压缩的内存”超过 1 GB 且“虚拟内存”远高于实际占用，说明它在频繁申请却未释放内存。
识别泄漏的典型表现
内存泄漏不会立刻报错，但会在活动监视器里留下痕迹：
- 某个进程的“内存”数值在闲置状态下仍每分钟上涨 50–200 MB
- 关闭相关操作（如停止本地服务）后，该进程内存不回落，甚至继续爬升
- 重启该进程后内存立即归零，几小时后又回到高位
- 内存压力图长期处于黄色或红色，而“被压缩的内存”却接近 0 ——说明它占着内存不放，系统无法压缩回收
用终端命令交叉验证
图形界面刷新有延迟，终端能捕捉更细粒度的变化：
- 运行 top -o vsize -s 5，观察可疑进程的 VSIZE（虚拟内存大小）是否单向增长
- 执行 ps aux --sort=-%mem | head -10，确认前 10 名是否为你预期的开发服务，而非插件或后台守护进程
- 对疑似进程，用 vmmap -w [PID] 查看内存区域分布；若“allocated”远大于“resident”，提示存在大量未释放堆内存
区分用户进程与内核泄漏
如果所有应用内存都正常，但内存压力仍居高不下，问题可能出在内核层：
- 在活动监视器中点左下角齿轮 → “显示所有进程”，再按“用户”列筛选 root 或 daemon 进程
- 终端运行 kextstat | grep -v com.apple，列出第三方内核扩展，重点关注 Parallels、VMware、Logitech、ROG 或清理类工具的驱动
- 用 sudo kmutil unload -b com.example.driver 临时卸载可疑驱动，观察 15 分钟内内存压力是否明显回落
