直接讲结论：如果你在 Windows 上遇到“内存不足”提示、软件闪退、编译到一半进程被杀，甚至直接蓝屏，大概率不是物理内存真的被“用满”了，而是虚拟内存（也就是页面文件 pagefile.sys）设置得不合理。这个文件平时安安静静躺在 C 盘，很多人从装好系统那天起就没管过它，直到 16GB 内存吃紧、32GB 内存还报 OOM，才突然发现它是个绕不过去的坑。
这篇文章我不想念微软文档，也不会让你去“右键我的电脑——属性——高级系统设置”一路点到底就完事。我拆开讲三件事：虚拟内存到底在干什么、大小怎么算、以及当你真的遇到 OOM 时该按什么顺序排查。文里所有的数值和建议都来自我自己的测试和踩坑，不是从别处抄的参数表。适合觉得电脑莫名其妙卡、开发环境经常崩、或者刚入手新电脑想一次性配好内存管理的朋友。
1. 先分清“物理内存不够”和“OOM 被杀”是两码事
1.1 虚拟内存到底在“虚拟”什么
虚拟内存不是真正的内存条，它是一个由 Windows 内存管理器控制的地址空间抽象层。每一个 64 位进程在用户态默认可以拿到 128TB 的虚拟地址空间，物理内存大小根本限制不了这个数字。真正限制程序的是“已被提交的内存”（committed memory），也就是进程向系统承诺要用的那一部分地址，而这部分是有物理内存加页面文件共同兜底的。
所以页面文件的实际作用，是在物理内存压力大的时候，把一些暂时不用的内存页挪到磁盘上，腾出物理内存给正在活跃的页面用。你可以把它想象成一个“内存的停车场”：物理内存是门口的车位，页面文件是远处的备用停车场，车多的时候，管理员把不临停的车挪到备用场去。
这里有个很容易被误解的点：不是只有内存爆了才会用页面文件。Windows 的内存管理器是主动型的，它不等到内存满了才换页，而是基于内存压力、进程优先级、页面访问频率做动态平衡。所以你在任务管理器里看到“内存占用 60%”，后台可能已经在写页面文件了，这很正常，不代表系统有问题。
1.2 OOM，是物理内存不够还是提交上限不够
做开发的朋友对 OOM 最熟悉，但很多人在 Windows 上排查 OOM 时，方向是错的。Java 应用抛OutOfMemoryError，很多人第一反应是调大堆内存 -Xmx，但是当这个错误来自操作系统层面时（比如进程直接崩了、提示“memory allocation failed”），问题往往出在“提交限制”（commit limit）上。
提交限制的计算公式是物理内存大小加页面文件大小（严格来说还要算上一些硬件保留的区域）。当系统总提交量逼近这个上限时，即使你物理内存还有很多剩余，内存分配依然会失败，因为 Windows 认为“已提交但未实际使用的承诺”已经没有足够的后备存储了。
举例：你的机器是 16GB 物理内存 + 4GB 页面文件，提交限制大约是 20GB。如果同时开了三个浏览器、一个 IDE、一个 Docker Desktop，再跑几个 Node 进程，提交量轻松到 18GB 以上。此时哪怕另一个进程只需要再申请 500MB 内存，Windows 也会拒绝，因为剩余可提交空间不够。表面看是“内存不足”，本质是“提交上限不足”。
所以排查 OOM，第一步不是加物理内存，先看“提交量/提交上限”这两个数字。打开任务管理器——性能——内存，最下面一行就是“提交”，斜杠前面的数字是当前已提交量，后面是提交限制。如果前者占后者的比例长期超过 90%，那问题基本出在虚拟内存配置上。
2. 三种页面文件模式，每一种都有人用错过
2.1 自动管理、自定义、禁用，三者的真实行为差异
Windows 提供三种页面文件模式，很多人并不知道它们之间的机制差异，导致配置时机不对、改了没生效、甚至改完直接开不了机。
系统管理的大小：Windows 根据内存压力、崩溃转储需求、磁盘剩余空间动态调整 pagefile.sys 大小。优点是不用操心，缺点是它扩张时会产生磁盘碎片，而且在极端场景下它的扩张速度跟不上内存申请速度，就会出现“明明硬盘还有空间，内存分配却失败了”的情况。我一直不推荐服务器和开发机用这个模式，因为不可预期。
自定义大小：手动指定初始大小和最大值。这是最可控的方式，但有两个前提——你设置的数值不能小于系统崩溃转储所需空间（后面细说），并且你的 C 盘得预留出足够的空间。
禁用页面文件：这个选项存在于设置面板里，但微软其实不推荐你用。在极少数物理内存充足的场景下，禁用后系统确实会减少不必要的磁盘写入，但代价是牺牲掉 Windows 的崩溃转储能力，而且很多大型应用（比如 Photoshop 这类）在使用内存映射文件时，会默认依赖系统存在页面文件。禁用后导致的后果通常是：内存压力一来，系统直接崩溃，连 dump 文件都没有，你根本不知道是怎么回事。
2.2 设置大小的计算思路，不是“内存的多少倍”那么简单
老一代人流传的“虚拟内存 = 物理内存的 1.5 倍/2 倍”是机械时代的说法，那会儿物理内存才几百 MB、GB，页面文件确实有这么设的。但到了 16GB、32GB 甚至更大内存的时代，这个公式早就不成立了。因为物理内存足够大时，正常负载根本不需要太多换页空间，页面文件更多的是一种土层保护网。你要做的是根据提交峰值来推算，而不是按内存倍数拍脑袋。
先开个 PowerShell 或者 CMD，试试这套命令：
Get-Counter '\Memory\Committed Bytes','\Memory\Commit Limit' -SampleInterval 1 -MaxSamples 30跑一段时间，比如编译项目、开应用、做你平时最重的操作，观察输出的最大值。如果你的实际操作中已提交内存最高到过 18GB，当前物理内存是 16GB，那么页面文件至少要给到 4GB 作为兜底，最好给到 8GB。
出现蓝屏时，Windows 需要“内核内存转储”文件来排查问题。如果页面文件太小，系统可能无法写入完整 dump。微软官方文档提供的参考值：内核转储需要的内存至少等同于物理内存大小。也就是说，如果你希望蓝屏时能拿到完整 dump，页面文件大小应不小于物理内存大小。很多只开“小内存转储”的朋友可以忽略这一点，但如果你常做驱动调试或者系统稳定性测试，这一点很关键。
2.3 一个半小时测试法：判断当前虚拟内存是否够用
有时候我们不缺配置，缺的是“当前配置到底够不够”的确认手段。除了性能计数器，我习惯用一个更直观的检测方法：打开资源监视器，切到内存选项卡，看“硬错误/秒”这个计数器。
硬错误的意思是系统需要从磁盘上的页面文件读取数据，而不是从物理内存命中。这个数字长期为 0 或非常低，说明你的页面文件基本闲着，够用。如果这个数字经常跳动、偏高（比如稳定超过每秒几十个），说明物理内存压力很大，系统已经把大量页面移到了页面文件上，此时一旦读写跟不上，就会感觉明显卡顿。
测试方法是：按 Win+R，输入resmon打开资源监视器，切到“内存”选项卡，然后正常做你的重负载操作 30 分钟以上。期间观察“硬错误/秒”的变化曲线。若曲线长期在中高位震荡，我的建议是增加页面文件大小，或者物理内存。如果这个数字几乎贴着 0，那么你的虚拟内存配置没有问题的，不要再为“设置多少”而失眠了。
3. Win10/Win11 虚拟内存配置实操：从面板到命令行的全路径
3.1 图形界面路径与设置步骤
图形界面配置方法不复杂，但有几个细节很容易错过：
- Win + S 搜索“高级系统设置”，打开。
- 切到“高级”选项卡，找到“性能”区域，点“设置”。
- 切到“高级”选项卡，在“虚拟内存”区域点“更改”。
- 系统默认勾选了“自动管理所有驱动器的分页文件大小”，先把这个勾取消。
- 选择 C 盘，选中“自定义大小”，填上你的初始大小和最大值。
第 4 步是最容易出问题的。很多人直接在 C 盘填了自定义大小，但没有先取消“自动管理”，导致表面看起来设置了，实际上 Windows 还是在按自己的策略管理页面文件。设置完成后，记得点“设置”按钮，再点“确定”，否则填的值不会写入注册表。
还有一个常见疑惑：初始大小和最大值填相同值到底行不行？我告诉你，行，而且是多数服务器环境的标准做法。填相同的值意味着页面文件大小固定，不会动态伸缩。好处是避免了文件扩张时的磁盘碎片，也避免了“某次突发写入导致页面文件扩张时卡顿”的情况。坏处是你必须把最大值设得足够大，否则一旦峰值超过这个固定值，系统照样会报 OOM。所以我个人的做法是：初始大小和最大值相同，数值按上一节的提交峰值推出来的上限来，同时多留 20%~30% 的余量。
3.2 命令行配置，适合需要脚本化的人
如果是新装系统、多台机器统一配置，或者远程操作时不想开图形界面，用命令行更快。注意，在 Windows 上配置页面文件最正统的命令行工具是wmic，虽然在新版 Windows 11 中它已不再默认推荐，但大多数机器仍可用。以管理员身份打开 PowerShell：
# 查看当前所有磁盘的页面文件配置 wmic pagefile list /format:list # 删除 C 盘页面文件请小心，先创建一个新的，再重启 wmic pagefileset where name="C:\\pagefile.sys" delete创建或修改页面文件的更底层操作其实要走注册表：
# 定位到分页文件管理键 # HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management # PagingFiles 这个多字符串值，格式是 "C:\pagefile.sys 4096 8192" # 4096 是初始大小（MB），8192 是最大值（MB） Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" -Name "PagingFiles" -Value "C:\pagefile.sys 4096 8192"修改注册表后必须重启才会生效。利用这一点，你可以先设置好新值，然后找一个合适的时间重启。
3.3 配置后如何确认已生效
重启完成后，打开 C 盘根目录，如果开启了“显示隐藏文件和系统文件”，你应该能看到 pagefile.sys。它的实际大小就是你设置的初始大小。此时再用wmic pagefile list /format:list查看，能直接看到当前大小和峰值使用量。
另外注意一个容易忽略的点：页面文件所在的盘必须有足够的 NTFS 空间。Windows 11 的休眠文件、系统还原点也会占 C 盘空间，别等配置完才发现磁盘满了，实际写入页面文件时系统直接罢工。建议至少保留页面文件大小 1.5 倍以上的空闲空间。
4. OOM 问题排查链路：先判断方向，再动手调
4.1 事件查看器里最有价值的三个日志来源
遇到 OOM，第一件该做的事不是马上改页面文件，而是打开事件查看器，看日志，确切地知道是谁、在什么时间、以什么方式被杀掉的。Win+R 输入eventvwr，重点看三个位置：
- Windows 日志 — 系统：查来源为 “Resource-Exhaustion-Detector” 的事件，事件 ID 2004。这个事件明确告诉你“Windows 已从虚拟内存中释放了多少空间给应用程序”，如果频繁出现，说明系统提交压力大。
- Windows 日志 — 应用程序：查错误级别的事件，看是否有应用崩溃，崩溃模块是
ntdll.dll还是kernelbase.dll。 - 应用程序和服务日志 — Microsoft — Windows — MemoryDiagnostics：如果你之前跑过内存诊断工具，结果在这里。
一个关键思路：先把日志和提交量数据对齐。如果事件 2004 频繁出现，且任务管理器的提交量接近提交上限，那么这基本是虚拟内存配置不够的问题。如果 2004 不出现，但某个 Java 进程还是报了 OOM，那就要往下看进程自己的堆内存设置，而不应全怪系统。
4.2 进程崩溃和系统崩溃，方向完全相反
很多人遇到“程序崩溃”，第一反应就是“内存不够”，接着就冲去调虚拟内存。但实际上，进程自身堆内存不足导致的 OOM，和系统提交量不足导致的 OOM，处理方式完全不同。
一个数据库进程如果设置了 JVM 堆上限是 4GB，而在运行中堆涨到了 4GB 上限，进程会抛出java.lang.OutOfMemoryError: Java heap space。这个错误和系统页面文件的大小没有关系，唯一的解法是调大该进程的堆上限，或者优化应用的内存占用。
另一种情况是进程试图向操作系统申请内存时，系统已经没有足够的内存可提交，此时会报java.lang.OutOfMemoryError: Unable to create new native thread或者干脆进程被 Windows 直接杀掉（进程消失，没有任何错误窗口）。这种情况才和系统虚拟内存、提交限制有关系。
判断方法很简单：看任务管理器在进程崩溃前后的“已提交内存”数值。如果已提交内存达到了提交上限附近（比如 95% 以上），那就是系统级内存不足；如果已提交内存离上限还很远，则优先检查进程自身的配置。
4.3 用性能监视器确认“页面文件压力峰值”
如果你觉得看计数器不够直观，就用 Windows 自带的性能监视器做一次长达数小时的采样，存成日志文件，最后再复盘。
在性能监视器里添加计数器，我选的是这几个核心项：
| 计数器 | 作用 |
|---|---|
| Memory\Committed Bytes | 当前提交内存总量 |
| Memory\Commit Limit | 当前提交上限 |
| Memory\Pages/sec | 每秒页面换入换出次数，过大意味着严重换页 |
| Paging File% Usage | 页面文件当前使用率峰值 |
把这几个计数器组合起来看，可以快速定位问题：如果 Commit Limit 和 Committed Bytes 的差值长期小于 2GB，那么页面文件扩容是首要任务。如果 Paging File% Usage 长期接近 100%，说明你的页面文件大小确实不够。如果 Pages/sec 非常高，同时硬错误也高，说明物理内存已经严重不足，此时加虚拟内存只是缓解，治本的方法是加物理内存或者减少同时运行的程序。
5. 不同内存容量、不同使用场景的页面文件方案
5.1 8GB / 16GB / 32GB 内存的起步参考值
以下数值是我在测试机上实测后得出的参考值，适合大多数人作为起点。注意是“起点”，不是“终值”，最终还是要靠前面说的性能监视器数据来校订。
| 物理内存 | 页面文件初始值 | 页面文件最大值 | 适用场景 |
|---|---|---|---|
| 8GB | 4096MB | 8192MB | 轻度办公、网页浏览、轻度开发 |
| 16GB | 4096MB | 8192MB | 常规开发、虚拟机、PS 修图 |
| 32GB | 2048MB | 4096MB | 重度开发、大型编译、多 VM |
| 64GB 及以上 | 1024MB 或 2048MB | 2048MB ~ 4096MB | 工作站、罕见的提交峰值兜底 |
先说 16GB 这个最常见的档位。很多朋友的误解是：内存都 16GB 了，页面文件开个 512MB 意思一下就行。但实际上，如果你开 Docker Desktop，它默认会给 WSL2 保留相当数量的内存；如果再加上 Electron 系的应用（VS Code、Discord、Slack）和浏览器，提交峰值轻松超过 20GB。16GB 内存加 4GB 页面文件就是 20GB 的提交上限，看起来刚好，但一旦编译大型前端项目或者启动 Elasticsearch，提交量就会冲破这个数。所以我给 16GB 机器的建议是初始 8GB、最大 8GB 起步，不是因为我喜欢大数值，而是因为现在应用的提交峰值真的比以前高太多。
32GB 内存的机器是不是可以不用页面文件？我用真实数据来回答：不推荐禁用。哪怕你日常使用中物理内存还剩 10GB，但 Windows 的崩溃转储机制默认依赖页面文件。如果你禁用了，一个偶发蓝屏就可能让你丢掉所有排查依据。另一个更现实的坑是：某些数据库安装程序（比如 MySQL 8 的安装向导）在检测到系统没有页面文件时，会直接弹警告并中止安装。不要为了省几个 GB 的磁盘空间去禁用页面文件，不值得。
5.2 SSD 环境下虚拟内存设置的特殊性
SSD 用户经常陷入一个纠结：页面文件频繁读写，会不会伤固态硬盘？
先说结论：正常设置页面文件对 SSD 寿命的影响，远小于你下载 BT、安装大型游戏、甚至 Windows 更新这些操作的写入量。现代固态硬盘的写入寿命是以 TBW 计算的，页面文件的写入量在日常负载下非常小。我专门用类资源监视器测过一台只安装基本开发环境的机器，一整天下来页面文件的写入量一般不超过几百 MB，这个量对 SSD 寿命的影响可以忽略不计。
但 SSD 上有几个优化点倒是值得做：一是尽量让页面文件留在系统盘，因为系统盘通常是最快的 NVMe 盘；二是不要和系统镜像、休眠文件抢空间，提前预留；三是不要为了“减少写入”就把页面文件设成固定最小值。我看到过一种说法是“我的内存很大，我把页面文件设到 16MB 固定值”，这种做法会在内存压力突增时严重拖慢系统，甚至直接触发提交限制错误。
5.3 跑 Docker、Elasticsearch、MySQL 等服务的虚拟内存考量
这个坑很典型：Docker Desktop 在 Windows 上默认使用 WSL2 后端，WSL2 的内存管理方式和原生 Windows 不同。WSL2 文件系统缓存在默认配置下会吞掉大量内存，导致 Windows 提交量飙升。如果你在 Windows 上跑 Docker，建议先看 Docker Desktop 的设置——Settings — Resources — Advanced，里面可以限制 WSL2 的总内存（默认是宿主机内存的 50%）。
Elasticsearch 是另一个重灾区。ES 的 JVM 默认堆内存是物理内存的四分之一左右，32GB 机器起个默认 ES 就吃掉 8GB。同时 ES 的内存映射需要足够的地址空间，这在 Linux 上对应vm.max_map_count，Windows 上虽然没有这么直接的对应参数，但页面文件太小会在启动时触发 mmap 失败。我实测过一台 16GB 内存的笔记本，跑 Docker Desktop + ES + Kibana + MySQL，页面文件给到了 12GB 才彻底稳住。这不是什么标准答案，但说明了一个事实：服务越多，页面文件越不能按机械时代的比例来算。
MySQL 在 Windows 上的安装其实是对页面文件最敏感的场景之一。我之前在测试机上把页面文件禁用后，MySQL 8.0 的安装程序直接在中途退出了，错误信息提到了内存映射失败。这让我重新意识到，有些软件的安装器自身就会检测页面文件是否存在，并把它作为系统健康度的一部分。
5.4 多用户远程桌面和虚拟化环境下的页面文件策略
如果你管理一台多人远程登录的 Windows Server，情况就更复杂了。每个用户会话都会产生独立的桌面堆、进程和内存提交。这时候页面文件不是一个“建议值”的问题，而是一个会直接影响稳定性的参数。
我的建议是把页面文件固定在一个足够大的值，然后定期通过性能监视器收集 Commit Limit 和 Committed Bytes 的趋势数据。如果发现提交峰值有上升趋势，就提前扩容，而不是等用户报问题后再救火。在虚拟化宿主机上，还要注意不要让页面文件盘和虚拟机镜像共享同一块物理磁盘，否则磁盘 IO 会被同时打满。
6. 配置虚拟内存时的常见误区与我的实测结论
6.1 “禁用页面文件提升性能”为什么是错的
这个说法在我刚接触 Windows 时就有，到今天还在流传。理由是“物理内存够大，完全不需要页面文件，省去磁盘读写当然更快”。听起来有道理，但它忽略了一个关键机制：Windows 内核在分配某些类型的内存池时会要求存在后备存储。如果你完全禁用了页面文件，这些内存池的可用空间会大幅收缩，被限制在物理内存的实际范围内。
我做过一个简单测试：一台 32GB 内存的机器，禁用页面文件后，运行 Photoshop 处理 50 张图层较多的工程文件，系统在某个阶段弹出了“内存不足”的警告，而任务管理器显示物理内存还剩余 12GB。重新启用页面文件后（4GB 固定），同样操作完全正常。结论很清楚：物理内存大不代表提交上限宽裕，Windows 的现代内存管理器在设计上就假设页面文件始终存在。
6.2 固定初始大小和最大值到底图什么
前面说了，我推荐初始大小和最大值相同。这里补充一个操作细节：如果系统自动管理页面文件，pagefile.sys 会随着系统压力时大时小。当它需要扩容时，Windows 会立即占用新的磁盘空间，而缩小时又会释放。问题在于这个“伸缩“过程本身会导致系统性能抖动——尤其是当页面文件所在的磁盘同时承担日志、数据库文件写入时。
我在一台 MySQL 服务器上实测过：系统管理模式下，MySQL 在写入高峰期时，pagefile.sys 从 4GB 自动扩到 8GB，而扩容期间查询响应时间出现了明显的尖刺。改成固定 8GB 后，同样的负载下响应曲线平稳了很多。这也是很多数据库管理员坚持把页面文件大小固定的底层原因。
6.3 页面文件搬到非系统盘会更好吗？
这个问题的答案取决于“非系统盘”是什么盘。如果你把它搬到一个机械硬盘上，而系统盘是 SSD，那这是彻头彻尾的负优化。因为 Windows 页面文件和程序、驱动、系统缓存都在争抢 IO，如果页面文件在更慢的盘上，内存压力时的延迟会成倍增加。如果你把页面文件搬到另一个 SSD 上，并且该 SSD 的 IO 负载不高，那确实能分散系统盘的压力，这是一个可以接受的优化。
但有一个精确的操作顺序问题：你把页面文件从 C 盘移到 D 盘之后，必须在 C 盘保留一个 512MB 或 1024MB 的“小型页面文件”，否则 Windows 的崩溃转储依然可能失败。微软官方没有强制要求，但我在调试驱动时实测过，只有 D 盘有页面文件的情况下，系统蓝屏后的 dump 文件经常是残缺的。
6.4 关于“虚拟内存写在哪个盘”的最终建议
排列一个最省心的方案，基本上适用于七成以上的开发和个人用户：
- C 盘（系统盘、NVMe SSD）上保留
4096~8192MB的固定页面文件。 - 如果 C 盘空间紧张，可以把 D 盘（也是 SSD）上放一个
8192MB的页面文件，同时 C 盘保留1024MB。 - 不要放机械盘。不要在 U 盘、移动硬盘上创建页面文件。Windows 在设备移除时对页面文件的处理非常不友好，轻则蓝屏，重则数据丢失。
- 内存 32GB 及以上的机器，页面文件没有必要大于 8192MB，除非你的业务确实出现了超过物理内存的提交峰值。
7. 配置完之后的验证与长期维护建议
7.1 三个命令确认配置没有“白改”
很多人改完设置发现一段时间后又出现 OOM，于是怀疑自己的设置没生效。用下面三个命令分别验证：
# 确认当前页面文件路径和大小 wmic pagefile list /format:list # 查看虚拟内存相关计数器当前值 Get-Counter '\Memory\Committed Bytes','\Memory\Commit Limit' # 查看所有盘符空间，确认预留空间充足 Get-PSDrive -PSProvider FileSystem如果一切正常，你会看到类似这样的输出：
AllocatedBaseSize=8192 CurrentUsage=512 Name=C:\pagefile.sys PeakUsage=2048PeakUsage是历史最高使用量，这个数值特别有用。它可以告诉你当前设置的页面文件是否够用：如果它长期接近AllocatedBaseSize，说明设置的初始大小太紧张；如果它只有几百 MB，说明你的页面文件在很大程度上是“兜底配置”，那就可以考虑缩小一些，省出磁盘空间。
7.2 定期观察提交量趋势
页面文件设置好后不是一劳永逸的。你的使用习惯、安装的软件、开发项目的规模都会变，提交峰值也会跟着变。我建议每隔一两个月用性能监视器导出一份提交量趋势数据，对比之前的结果。如果提交峰值明显上升，就果断扩容页面文件。相反，如果物理内存已经升级（比如从 16GB 升到 32GB），且提交峰值远低于新的物理内存大小，那反而应该把页面文件调小，避免长期占用过多磁盘空间。
7.3 配合重启习惯，让改动真正落地
无论你是通过图形界面还是注册表改的页面文件，都需要重启才能生效。有些朋友改完不重启，继续高强度运行，然后得出一个“改了没用”的结论。这其实是操作流程的问题。重启之后，用上面的第一个命令再看一眼页面文件大小，确认它已经变成你设置的值，再继续干活。
多提一句：系统更新（尤其是 Windows 大版本更新）偶尔会重置某些虚拟内存设置。我在从 Win10 升级到 Win11 的测试机上遇到过几次“自定义页面文件被重置回自动管理”的情况。升级完之后，花一分钟重新确认一下设置，能省掉后面很多莫名其妙的偶发 OOM。
最后再分享一个小技巧：如果你是在一台经常跑大型编译或容器化开发的机器上调整页面文件，建议把页面文件最大值设成初始值的 1.5 倍左右，而不是完全相等。这样做的原因是，大型编译工具链（比如 MSVC、Gradle、前端 webpack 打包）的提交峰值通常来得很猛，而且属于“瞬时高并发”。固定的页面文件大小如果卡得太死，峰值一到，系统会临时“强行分配”更多磁盘空间，过程中的卡顿比碎片化还明显。留一点伸缩余量，既能避免大多数 OOM，又不会让页面文件长时间占用过多空间。至于 1.5 倍还是 2 倍，没必要太纠结，有余量就比没余量强。
