“您的mac内存已严重不足”警告且内存压力持续红色、关闭应用后不回落，说明存在内存泄漏；需通过底部内存压力图（红色超2分钟为强信号）、被压缩内存低但交换升高、进程内存持续上涨、终端vmmap/footprint等多指标交叉验证定位泄漏源。
当Mac弹出“您的Mac内存已严重不足”警告，且活动监视器中内存压力持续红色、关闭应用后数值不回落，说明系统很可能正遭遇内存泄漏——不是缓存未释放，而是进程申请了内存却永远不归还，必须通过多层指标交叉比对才能揪出真凶。
先看内存压力图与整体趋势
按下Command + 空格→输入“活动监视器”→回车启动→点击顶部“内存”标签页。直接滚动到底部，盯住标有“内存压力”的横向色条：绿色表示健康，黄色说明系统已开始压缩非活跃内存，【红色持续超过 2 分钟】是内存泄漏的强信号——此时 macOS 正高频读写 SSD 上的交换文件，卡顿和彩虹转圈已成常态。
观察右上角“已压缩内存”数值：若长期高于 2 GB，而“已使用的交换”也在缓慢爬升（如从 0 增至 800 MB），说明物理内存长期被占着不放，系统被迫用硬盘硬扛。
定位可疑用户进程
第一步：单击表头“内存”列一次，让进程按实际占用从高到低排序；
第二步：右键任意列标题→勾选“被压缩的内存”和“已使用的交换”；
第三步：在右上角搜索栏输入常见泄漏源关键词，如 Code Helper、Docker Desktop、node、qemu-system、Slack Helper、AdobeIPCBroker；
第四步：对准某进程连续观察 60 秒——若“内存”值每 10 秒上涨 50–150 MB，同时“被压缩的内存”始终为 0 或低于 10 MB，基本可判定该进程存在泄漏。
特别注意名称含“Helper”“Renderer”“Agent”的后台进程：它们常由浏览器、VS Code、Figma 或 Adobe 软件衍生，不显示窗口却独占数 GB 内存，且 CPU 占用几乎为 0——这正是泄漏的典型特征：占着内存，却不干活。
用终端命令验证泄漏行为
方法一：打开终端→输入 top -o rsize -s 2 回车；等待刷新后，看 COMMAND 列对应进程的 RSIZE 值（单位字节），比如 4.2G 表示它实打实占了 4.2 GB 物理内存，没共享、没压缩、没释放；
方法二：若图形界面已卡死，改用 ps aux --sort=-rss | head -n 11，这条命令绕过 GUI 渲染机制，输出前 10 个 RSS（驻留集大小）最高的进程，更贴近内核真实分配；
方法三：对疑似进程 PID（如 12345），运行 vmmap -w 12345 | grep -E "(allocated|resident)"——若 allocated（已分配）远大于 resident（已驻留），例如 allocated=8.1G、resident=1.3G，说明它申请了大量堆内存却未真正使用，也未释放，极可能是泄漏。
排查内核级泄漏（第三方驱动）
如果所有用户进程内存都正常，但内存压力仍长期红黄、kernel_task 占用突增至 3 GB 以上，问题大概率出在内核扩展（kext）：运行 kextstat | grep -v com.apple，重点关注 Parallels、VMware、Logitech、ROG、CleanMyMac、Avast 等厂商的驱动；
再执行 sudo footprint -t system -w 10 | grep "Kernel Allocations"，每 10 秒刷新一次内核内存分配量，若数值单向增长（如从 1.2G → 1.7G → 2.1G），且增长节奏与某个 kext 加载时间吻合，就基本锁定了泄漏源；
验证方式：记下当前 kernel_task 占用值→用 sudo kmutil unload -b com.parallels.kext.prl_hypervisor 卸载一个可疑驱动→观察活动监视器中内存压力是否在 15 分钟内明显回落。
注意：卸载前需确认 SIP 状态，部分驱动需先禁用 SIP 才能操作，否则命令会失败。
交叉印证日志线索
在终端运行：log show --predicate 'eventMessage contains "zalloc" or eventMessage contains "leak"' --last 1h；重点查找是否反复出现 zalloc: allocation failed 或 kern.zalloc: potential leak detected 类报错；若某条日志频繁关联同一 Bundle ID（如 com.logitech.driver.LogiOptionsDaemon），就是泄漏的铁证。
