关键不是看“用了多少内存”，而是通过活动监视器勾选“虚拟内存”和“被压缩的内存”列，按虚拟内存排序识别coreaudiod、mds_stores等系统进程的异常地址空间占用（如虚占达4–8 GB），结合非活跃状态、高VM低CPU、子进程分层视图及vm_stat/ps辅助验证，定位真实虚拟内存压力源。

在 macos 活动监视器中查看系统进程的虚拟空间分配，关键不是看“用了多少内存”，而是理解虚拟内存（vm）如何被分配、压缩和交换——尤其是系统进程这类常驻后台、不显眼但可能大量申请地址空间的服务。

重点看“虚拟内存”相关列，而非仅“内存”数值

系统进程（如 coreaudiod、coreservicesd、mds_stores、cloudd）通常物理内存占用不高，但虚拟地址空间（Virtual Memory, VM）可能极大。默认视图不显示这些，需手动启用：

• 打开活动监视器 → 点击顶部菜单「显示」→「列」→ 勾选虚拟内存和被压缩的内存
• 点击「虚拟内存」列标题排序，把虚占空间最大的进程顶到前面（常见如 Electron 类进程虚占 3–5 GB，某些索引服务可达 8 GB+）
• 注意区分：虚拟内存是进程申请的地址空间总量（含未实际使用的部分），内存列才是当前真实占用的物理 RAM

识别异常虚拟空间行为的三个信号

单看数值容易误判，要结合状态与趋势判断是否真有问题：

macOS Automator Services

部署和使用军舰的 macOS Automator 自动化服务集合。包含 5 个实用工作流：PDF转JPG、PNG重命名并转JPG、图像拼接、解压RAR、顺序命名图像文件。一键安装所有服务到 ~/Library/Services/ 目录。使用场景：(1) "安装我的自动化服务"，(2) "部署所有 Automato...

下载

• 虚拟内存远超物理内存且持续增长：比如某个 mds_stores 进程 VM 从 2 GB 涨到 6 GB，而“内存”列只增了 100 MB，说明它在反复 mmap 大量文件却未释放，可能卡在索引异常中
• 被压缩的内存高 + 虚拟内存高 + CPU 占用低：典型“挂机型”——进程没干活，却锁着大量虚拟页，系统被迫压缩它腾空间
• 非活跃状态下仍维持巨大虚拟空间：切换到「显示」→「非活跃进程」，再按「虚拟内存」排序，排前列的往往是问题源头（如残留的旧版 Dropbox Helper 或已崩溃但未清理的 launchd 子进程）

用分层视图揪出隐藏的子进程虚拟分配

很多系统级服务通过 launchd 启动子进程，主进程轻量，真正吃虚拟空间的是其子项：

• 点击「显示」→「所有进程，分层显示」
• 找带 ▶ 符号的父进程（如 com.apple.dock.agent、GoogleSoftwareUpdateAgent），逐个展开
• 观察子进程的「虚拟内存」值——有时一个 update_engine 子进程虚占 4.2 GB，而父进程才 80 MB
• 选中该子进程 → 点左上角「X」→「强制退出」，不会影响父服务，但能立即释放被锁定的虚拟地址空间

终端辅助验证虚拟内存压力源头

活动监视器无法直接标出哪个进程触发页面换出，但终端可补全这一环：

• 运行 vm_stat 1，关注 Pages swapped out 是否每秒持续增加（>5 页/秒即属频繁）
• 同时执行 ps aux --sort=-vsz | head -10，列出虚拟内存（vsz）最高的 10 个进程，确认是否为系统进程或其子项
• 若怀疑某服务（如 corespotlightd），可用 sudo lsof -p $(pgrep corespotlightd) | wc -l 查看它打开的文件数——超 2000 个常意味着索引陷入死循环，导致 VM 不断扩张