Mac M1 上市之后，关于虚拟内存的讨论几乎没停过，而讨论的焦点就是那个在后台默默写盘的 swap memory。8GB 版本刚铺开那阵子，论坛里一堆人晒检测工具截图，说自己新机器用了没几天，内置存储的累计写入量就冲到了几百 GB 甚至上 TB，矛头直指系统在疯狂交换内存页。随后「建议 Mac M1 关闭虚拟内存」这类说法就传开了，不少人把关闭 swap 当成了新机到手的第一项优化步骤。但我在几台 M1、M2 机器上反复折腾之后，结论没那么简单：有些场景确实该管一管 swap，可直接关掉这个动作，代价往往比收益大。这篇内容会把 swap 的运行机制、M1 统一内存架构下的特殊性、查看与限制 swap 的具体命令、以及我自己踩过的坑全部摊开讲，从刚上手的小白到天天泡在终端里的朋友，都能拿走能直接落地的东西。
1. 为什么 M1 的交换内存会被反复拿出来说
1.1 统一内存架构把 swap 推到了台前
M1 这一类芯片把 CPU、GPU、神经引擎和内存控制器塞进同一块封装里，内存是统一的，CPU 和 GPU 共用同一个池子。好处很直观：数据不用在两条内存之间来回拷，核显性能直接起飞；代价是这个池子的容量是焊死的，8GB 就永远是 8GB，既不能插条内存，也不能像早年那样在设置里给虚拟内存划一块固定大小的区域。于是当 GPU 和 CPU 同时抢内存时，系统只能靠交换文件把暂时用不上的内存页写到 SSD 上腾地方。这就是为什么同一套 macOS，早年的机型上没人天天盯着 swap 看，到了 M1 身上它却成了高频话题——不是它的行为变了，而是它变成了唯一的泄压阀，一旦内存吃紧，所有压力都会通过这个口子释放出来，任何异常都会被放大到肉眼可见。
还有一层原因容易被忽略：M1 的内存带宽非常高，系统在内存页的调度上比过去更激进，压缩和交换触发得也更频繁。这意味着同样的使用习惯，在 M1 上看到的 swap 数值可能比老机器更大，但未必代表系统出了问题。
1.2 「关闭 swap 能保护 SSD」这个说法是怎么来的
早些年那波讨论里，很多人用第三方工具去读机器内置存储的累计写入量，8GB 版本开着浏览器几十个标签页、外接一台 4K 显示器跑个一两天，读数就能窜到几百 GB，个别夸张的能报出 T 级别的数字。SSD 有写入寿命，这是常识，于是「swap 在偷偷磨我的硬盘」这条逻辑链看起来就天衣无缝了，紧接着就有人提出把负责交换文件的那个后台服务干掉。需要说明的是，后来也有观点认为部分工具的读数口径有问题，把一些非写入操作也算进了累计值，真实消耗并没有截图里那么吓人。但不管怎么讲，swap 会写盘这件事是真的，只是它的量级跟你日常使用强度强相关，和「会不会把盘写坏」之间还隔着好几道数量级，直接画等号是不严谨的。
我自己的做法是先别慌，把机器的实际写入速率记下来，连续观察一周，再决定要不要动手，比看了两张截图就去改系统稳妥得多。
1.3 先明确一件事：macOS 没有给你标准的关闭开关
Linux 上你有一堆旋钮：独立交换分区、swappiness 参数、zram 压缩块设备，想怎么调就怎么调。macOS 完全不是这个路子。系统设置里压根没有「虚拟内存」这一项，sysctl里能改的 vm 相关参数屈指可数，交换文件的创建和回收全由内核自己决定。这么设计的原因也不难理解，苹果的取向就是让用户别管，系统自己权衡。你想干预，只能绕到 launchd 层面去停掉那个负责交换文件的服务，或者通过内核启动参数去改压缩器的行为，两条路都属于非官方玩法，系统更新之后随时可能失效，甚至把机器搞成开不了机的状态。
提示：在动手之前，先把「怎么恢复」写清楚，比如恢复命令、恢复需要的启动方式，再开始改。改完当场验证，别等到第二天开机才发现进不去系统。
2. 把概念捋清楚：交换文件、内存压缩和内存压力
2.1 三者其实是一条流水线上的三道工序
很多人把虚拟内存、swap、内存压缩混成一个东西，导致看数据时越看越糊涂。按我的理解，它们是一条流水线上的三道工序：第一道是内存压缩，系统把那些不常用但还不能丢的内存页用算法压一压，继续留在物理内存里，只是占用变小了；第二道是交换，当压缩也腾不出足够空间时，系统把整页数据写进 SSD 上的交换文件，物理内存立刻释放；第三道才是内存压力，它是系统对「现在到底有多紧张」给出的综合评分，参考了压缩率、交换频率、页回收难度等一堆指标。你真正该盯的是第三道，而不是第一道的绝对数值。
打个生活化的比方：桌面就是物理内存，抽屉就是压缩区，仓库就是 SSD 上的交换文件。手头要用的东西摆桌面，暂时不用的塞抽屉压一压，抽屉塞满了才往仓库搬。仓库搬得越多，说明桌面和抽屉都已经到极限了。
2.2 用终端和活动监视器看穿真实占用
活动监视器的「内存」标签页里，底部有一行「已使用的交换空间」，这是最直观的入口。但只看这一个数字很容易误判，因为它表示的是当前累计落盘的量，不代表系统此刻有多难受。我一般配合终端一起看，几条命令就够：
# 看交换文件的整体用量 sysctl vm.swapusage # 看内存页的统计，重点是压缩器相关的几行 vm_stat # 直接给出内存压力的综合判断 memory_pressuresysctl vm.swapusage的输出长这样：
vm.swapusage: total = 4096.00M used = 1280.50M free = 2815.50M (encrypted)total是当前系统已分配的交换空间总量，used是真正写进去的量。注意total会随着负载动态增长，不是固定值，看到它变大别急着紧张。vm_stat的输出里，我关注的是Pages stored in compressor和Pages occupied by compressor这两个，前者是压缩后存储的页数，后者是压缩器实际占用的物理内存。M1 上的内存页大小是 16KB，所以把页数乘以 16384，再除以 1024 除以 1024，就是 MB 数。这个换算很关键，不然你会被几百万的页数吓到。
2.3 内存压力对照表：什么数值该紧张
活动监视器里那条压力曲线是彩色的，很多人不知道颜色代表什么。我整理成一张表，对着看就行。
| 压力状态 | 图形颜色 | 典型表现 | 建议动作 |
|---|---|---|---|
| 正常 | 绿色 | swap 用量小幅波动，压缩器占用不高 | 不用管，继续用 |
| 偏高 | 黄色 | swap 持续增长，切换应用有轻微迟滞 | 关掉几个不用的后台程序 |
| 紧张 | 红色 | 明显卡顿、风扇起转、窗口拖动掉帧 | 立即释放内存，必要时重启 |
| 持续红色 | 红色 | swap 总量不断突破，硬盘灯频繁 | 说明配置或工作流需要调整 |
注意：绿色状态下偶尔看到几百 MB 的 swap 是完全正常的，macOS 会主动把冷数据挪出去，这属于预防性动作，不是内存不够。
3. 关闭 swap 之前，先把这三笔账算明白
3.1 SSD 写入寿命这笔账到底怎么算
先给一组参考量级。现在主流的内置存储，按 TBW 算总写入寿命，512GB 和 1TB 版本的标称值通常在几百 TB 这个区间，具体数值各厂商不同，但量级是这样。假设你的硬盘 TBW 是 300TB，而你每天的 swap 写入是 20GB，一年下来大概是 7TB，理论上要四十多年才写到标称上限。就算你重度使用，每天 100GB，那也是八年往上。所以问题的关键从来不是「会不会写坏」，而是「你的写入量到底有多大」。
要拿到真实数字，可以装一套命令行工具把硬盘的 SMART 信息读出来，重点看两个属性：累计写入的总字节数和通电时间。不过要提前说明，不同机型、不同系统版本能读到的字段不一样，有些机器读出的是原始值，需要自己换算，有些干脆读不到，读不到也不用纠结，去第三方工具里看看有没有现成的换算结果就行。
算出日均写入之后，再对照标称 TBW，你大概率会发现焦虑是多余的。
3.2 关掉 swap 之后系统究竟会发生什么
这是最需要讲清楚的一点。swap 被关掉并不意味着内存不够时系统会「优雅地提醒你清理一下」，它的真实行为是：物理内存耗尽后，内存分配请求直接失败，正在运行的程序开始被强制结束，严重的时候整个图形界面会崩掉，屏幕卡住或者直接回到登录界面，没保存的工作全丢。这个过程非常突然，没有任何缓冲。
有人会说，那我只压缩不落盘不就行了？理论上系统确实有「只用压缩器、不配合交换」的模式，但 macOS 并没有把它做成官方支持的选项，相关的内核参数在不同系统版本上的表现差异很大，有的生效有的完全不起作用，而且一旦设置不当，可能连恢复都变麻烦。我的态度是，这条路可以研究，但不适合当作日常配置长期挂在主力机上。
更现实的做法是，把关闭 swap 当成一个「极限情况下的临时手段」，而不是常规优化项。
3.3 什么情况下值得动手，什么情况下纯属折腾
按我自己的经验，可以分成三类来看。
- 8GB 机型 + 明显的内存超载工作流：比如同时开大量浏览器标签页、跑虚拟机、剪视频，且内存压力长期红色。这种场景下值得做的不是关 swap，而是换机器或者彻底改工作流。
- 16GB 及以上机型：老实说基本不用考虑这件事，把内存管好就已经足够了，swap 只是偶尔兜底。
- 纯粹出于对硬盘寿命的担心：这类情况我的建议是先去测真实的日均写入量，用数据说话，多数人测完就不焦虑了。
真正值得花时间去做的，是减少 swap 的触发频率，而不是在它触发之后把出口堵死。
4. 实操：在 M1 上查看、压制和准关闭交换内存
4.1 一组命令看清 swap 现状
先把现状摸清楚，这一步不能跳。下面几条命令我基本是连着敲的：
# 1. 交换空间总览 sysctl vm.swapusage # 2. 内存页统计，配合 grep 只看关键行 vm_stat | grep -Ei "page size|compress|swap|free|wired" # 3. 交换文件实际占用的磁盘空间 ls -lh /private/var/vm/ # 4. 内存压力综合评分 memory_pressure第 3 条特别值得说，/private/var/vm/目录下会看到swapfile0、swapfile1这样的文件，用ls -lh能看到每个文件的大小。系统是按需一个个创建的，每个文件通常是 1GB 左右，用完回收。如果你看到七八个文件同时存在，那说明这台机器长期处于内存吃紧状态。
第 4 条memory_pressure会输出一长串，重点看最后那行关于系统整体内存状态的判断，以及可用内存的百分比。
4.2 调整内存压缩策略的正确姿势
内存压缩器相关的参数存在vm.compressor_mode这个变量里，用下面这条命令看当前值：
sysctl vm.compressor_mode桌面版系统默认是一个让压缩器和交换协同工作的模式，这也是为什么你会看到「压缩内存」和「交换空间」同时存在。网上流传过把它改成「只压缩不交换」的做法，但我不建议在没有完整回滚方案的情况下尝试，原因有三：一是不同系统版本的取值含义并不统一，抄来的数字未必对应你要的模式；二是这个参数改动可能影响系统稳定性，尤其在内存本来就紧张的机器上；三是它跟硬件、固件版本都有关系。
如果你确实想试，务实的流程是这样：
# 记录当前值，方便回滚 sysctl vm.compressor_mode # 设置启动参数（仅作为示例，务必先确认自己的系统版本是否支持） sudo nvram boot-args="vm_compressor=2" # 重启后验证 sysctl vm.compressor_mode # 需要回滚时 sudo nvram -d boot-args注意：
nvram这类操作属于内核级启动参数，部分机型和新版本系统会直接忽略它。设置完之后必须重启并立刻验证，不要假设它一定生效。如果验证发现没有变化，说明这条路在你这台机器上走不通，及时回滚，别反复试。
4.3 找出真正的内存黑洞，从源头减少 swap
与其纠结怎么关出口，不如把吃内存的大户揪出来。活动监视器的「内存」标签页按内存占用排序，能看个大概，但更细的信息在终端里：
# 按内存占用列出前 15 个进程 ps aux | sort -nrk 4 | head -n 15 # 看某个进程的详细信息 ps -o pid,rss,vsz,%mem,command -p 进程IDRSS是常驻内存，也就是真正占着物理内存的部分；%MEM是占总内存的百分比。这两个指标配合看，很容易发现异常进程。
浏览器是重灾区，尤其是标签页开得多的时候，每个标签页都可能是一个独立进程，其中一个内存泄漏就能吃掉好几个 GB。我自己的习惯是给浏览器装一个标签页休眠类的扩展，把长时间不看的页面挂起，效果立竿见影。
另外就是那些后台常驻的小工具，单个看着不起眼，十几个叠起来就是 1 到 2GB，8GB 机型上这个数字非常致命。
4.4 限制单应用与降低后台常驻的实战配置
把内存省下来这件事，靠的是习惯加上一点点配置。分享几个我一直在用的做法。
第一，登录项能砍就砍。系统设置里的「通用」→「登录项」，把那些开机自动启动、但你一周都用不上一次的程序全部移除。这一步在 8GB 机型上通常能省出几百 MB 到 1GB。
第二，浏览器只留一个主力。同时开两三个浏览器是最浪费内存的用法，内核不共享，缓存也各存一份。
第三，虚拟机和容器用完就退。这类程序一旦启动就会预留大块内存，挂着不用等于白占。至于在 M1 上装 Windows 虚拟机这类操作，本身就是内存消耗大户，跑之前先确认剩余内存是否够分。
第四，养成定期重启的习惯。macOS 长时间不重启，内存碎片和缓存会越积越多，重启一次往往能立刻改善压力状态。
第五，善用内存清理命令。装了命令行开发工具之后会有一个purge命令，它能强制回收一部分可回收的缓存：
# 强制回收文件缓存，需要管理员权限 sudo purge提示：
purge回收的是磁盘缓存这一类可回收内存，不会动正在运行的程序占用的内存，所以别指望它能解决所有的内存紧张，它更像是按下一次「刷新」。
5. 我的踩坑记录与问题速查表
5.1 关掉 swap 之后我把机器搞卡死的那次
讲个真实经历。早些年我在一台 8GB 的机器上按网上教程停掉了交换文件服务，重启之后跑了几天的日常使用，感觉还挺好，sysctl vm.swapusage显示用量为零，心里那叫一个舒坦。直到有一次我一边开着视频会议，一边在浏览器里查资料，还顺手打开了一个比较大的表格文件，内存瞬间打满，整个系统在没有任何预警的情况下直接黑掉，会议断了，未保存的内容也没了。重启之后我老老实实把服务恢复了回去。
那次之后我彻底想明白了：swap 是系统留给你的最后一道保险，它平时不出声，但关键时刻能救命。把保险拆掉，换来的只是账面上好看的数字。
还有一次更隐蔽的坑，我改了一个内核启动参数之后忘了记录原值，结果系统更新之后行为变了，折腾了半天才回滚。从那以后我养成一个习惯，任何系统级改动之前，先把命令和原值写在备忘录里。
5.2 常见疑问与排查对照表
| 现象 | 可能原因 | 排查与处理 |
|---|---|---|
| swap 用量一直是零 | 内存充足，系统没必要写盘 | 正常，不用管 |
| swap 总量突然涨到几 GB | 有程序短时大量占用内存 | 看活动监视器排序，找出大户 |
| 关掉 swap 后应用频繁闪退 | 物理内存耗尽，分配失败 | 立即恢复服务并重启 |
| 内存压力长期红色 | 硬件配置与工作流不匹配 | 削减后台程序，或升级机型 |
| 硬盘写入量增长很快 | 长期高负载触发频繁交换 | 测日均写入量，评估是否在合理区间 |
| 恢复命令执行后没变化 | 系统版本不支持该参数 | 换回官方默认行为，别硬刚 |
5.3 几台机器的长期观察数据
我手上有几台不同配置的机器，用来做长期对照，数据不一定有普适性，但能说明趋势。
| 配置 | 典型使用场景 | 日常 swap 用量 | 内存压力 |
|---|---|---|---|
| 8GB | 浏览器十几标签页 + 文档 | 500MB - 2GB 波动 | 经常黄色 |
| 8GB | 上述 + 视频会议 | 2GB 以上，频繁触发 | 偶尔红色 |
| 16GB | 浏览器几十标签页 + 开发工具 | 200MB - 1GB | 基本绿色 |
| 16GB | 上述 + 虚拟机 | 1GB - 3GB | 黄色为主 |
8GB 和 16GB 之间的差距，在最重的场景下非常直观。如果现在让我给建议，预算允许的话，内存尽量往上选一档，这比任何软件层面的优化都管用。
6. 不同人群该怎么选：一份可以直接抄的配置清单
6.1 8GB 机型用户的日常守则
8GB 是 swap 问题最集中的配置，因为它的余量本来就小。我的建议按优先级排：先把登录项清干净，只保留真正需要的；然后浏览器收敛到一个，标签页用休眠扩展管理；接着把不用的虚拟机、容器、大型编辑器全部退掉，别以为最小化了就不占内存；最后养成每周重启一次的习惯。这一套做完，多数人的内存压力能明显改善。至于关 swap，我的建议是别关，改完之后你会发现系统稳得多。
如果做完这些还是长期红色，那就说明工作流已经超出这台机器的能力了，这时候需要面对现实，而不是继续在系统层面抠。
6.2 16GB 及以上用户其实不用太焦虑
16GB 及以上的机型，日常办公和轻度开发场景下，swap 用量通常都很小，内存压力绝大部分时间在绿色。这类用户完全没必要看那些「关闭虚拟内存」的教程，跟着做反而是给自己找麻烦。真正需要关注的是极端场景，比如同时跑多个虚拟机、做大体量媒体处理，这时候看一眼压力曲线就够了，黄了就去关几个程序，比改系统参数靠谱得多。
6.3 长期重度负载用户的取舍
如果你长期跑重负载任务，swap 用量大是必然的，这时候要做的是两件事：第一，把机器的散热和供电环境弄好，高负载下温度上去了系统调度会更保守；第二，定期记录硬盘的累计写入量，通过趋势判断是否在正常范围。只要日均写入量在一个合理的量级内，就不用为寿命焦虑。真到了写不动的那天，那也是几年之后的事了，届时换机比现在折腾系统划算得多。
最后分享一个我自己的小习惯：每隔一段时间跑一次sysctl vm.swapusage和vm_stat，把关键数字记在一份表格里。数据攒到十几条之后，机器到底在什么工况下会吃紧、什么操作会触发大量交换，一目了然。这比任何一篇文章里的建议都更贴合你自己的使用方式，也更能帮你判断那台机器到底还能陪你走多远。
