pagefile.sys 能删吗？Windows 虚拟内存大小与位置配置指南

前几天帮同事看一台笔记本，C盘只剩3GB空间，他打开"此电脑"一看，根目录躺着一个16GB的 pagefile.sys，第一反应就是这玩意儿一看就是垃圾，删了不就完了。手动删被系统拒绝之后，他转头在网上找了个"一键清理系统隐藏文件"的脚本，照着执行了。重启之后的故事很经典：Chrome 开十几个标签就开始弹内存不足，某个修图软件打开大图直接闪退，最离谱的是蓝屏一次之后，连个转储文件都没留下，排查全靠猜。

这篇就围绕 Windows 里的分页文件（pagefile.sys）把话说清楚：它是什么、谁在用它、什么情况下真的可以动它、动的时候该按什么顺序来。不管你是刚学会看任务管理器的新手，还是天天泡在虚拟机和容器里的老手，看完至少能自己判断"我这台机器到底该不该留它、留多大、放在哪块盘"。

1. 从C盘根目录那个巨大的隐藏文件说起

1.1 pagefile.sys 是 Windows 的"内存溢出缓冲区"，但它不是可有可无的

先把定义摆正：pagefile.sys 是 Windows 的分页文件，也就是虚拟内存落到硬盘上的那部分实体。它默认位于系统盘根目录，属性是"隐藏 + 系统"，所以在资源管理器里要勾上"显示隐藏文件"才能看见。它的存在意义很直白——物理内存条是固定的一块，而进程申请的虚拟地址空间往往是物理内存的好几倍，中间那个差额就需要一块地方来兜底，这块地方就是分页文件。

很多人把它类比成 Linux 的 swap 分区，这个类比方向没错，但有个关键差异：Linux 的 swap 是一个独立分区或者交换文件，格式和文件系统分开管；Windows 的分页文件就是一个普通路径下的巨型文件，受 NTFS 管辖，可以被系统动态伸缩，也可以被搬到别的卷上。理解这一点很重要，因为它决定了后面所有操作——你在"虚拟内存"对话框里改的其实是一份路径 + 初始大小 + 最大值的配置清单，系统盘上的那个文件只是清单里的一项。

还有一点新手最容易误解：pagefile.sys 并不是"内存用满了才开始工作"。任务管理器里那个"内存压缩"进程，以及系统后台的页面调度，都可能在内存看起来还很宽裕的时候就往分页文件里写东西。所以你看到内存占用只有 50% 却仍然有磁盘上的分页活动，这属于正常现象，不是故障。

1.2 虚拟内存真正在干的三件事

把分页文件的作用拆开看，其实分三件事，理解了这三件事，你就能自己判断删除它的后果。

第一件是给"提交内存"兜底。每个进程申请内存时，系统会先记一笔账，叫提交（Commit），只有真正写入数据时才分配物理页。系统允许的提交总量上限叫提交限制，它约等于物理内存加上所有分页文件的大小之和。这就解释了为什么内存占用只有 70% 却会报"内存不足"——报错的其实是提交账本超了，不是物理内存满了。

第二件是承载不那么常用的页面。内存里有一些页是"改过但暂时没人读"的，比如你切到后台很久没动的编辑器、挂在后台的聊天工具。系统可以把这些页写进分页文件，把物理内存腾给正在前台干活的程序。等到那个后台程序再被切回来，再读回内存。这套机制叫主动分页，它的存在让前台程序能拿到更多可用内存，是有正面价值的，不是"性能损耗"。

第三件是支撑崩溃转储。蓝屏时系统要把内存内容写到硬盘上供事后分析，这个落点就在分页文件（或者专用转储文件）里。你把分页文件全关了，蓝屏就只剩一个错误码，没有转储可看。对个人用户来说这可能只是排查麻烦，对公司里做运维的人来说，这等于丢掉了唯一的现场证据。

1.3 物理内存、提交内存、分页文件三者是一本账

这三个概念混在一起讲最容易乱，我用一本账的方式说清楚。

物理内存是手头的现金，能立刻花掉；提交内存是已经签出去的欠条总额，包含现金加上"随时可以从别处调来的钱"；分页文件就是那个"别处"，也就是备用金库。系统不允许欠条总额超过现金加备用金的总额，一旦超过就拒绝新的借款申请，应用看到的就是"内存不足"。

在任务管理器→性能→内存里，你能看到三行关键数字：使用中（压缩）、已提交、已缓存。注意"已提交"那一栏是x / y的格式，分母就是提交限制。这个分母，就是你这台机器内存管理的天花板。把分母压小，等于自己把天花板拆低，而绝大多数人删 pagefile.sys 的动机只是想省点 C 盘空间，这买卖明显不划算。

2. 想删它之前，先搞清你缺的到底是空间还是内存

2.1 三个数字，三分钟判断你的机器是否真的在用分页文件

动手之前先做个体检，别凭感觉。打开任务管理器→性能→内存，记下三个数：物理内存总量、使用中、已提交（分子和分母）。然后打开资源监视器（运行框输入resmon），切到"内存"标签，看硬错误/秒这一项。

判断逻辑是这样的：

• 如果已提交的分子长期贴着分母跑（比如 15.6/16.0 GB），说明你的问题在提交账本，删分页文件只会让报错来得更快。
• 如果硬错误/秒长期大于 0 并且持续跳动，说明系统真的在读硬盘上的分页内容，这时候分页文件的位置和速度就很关键。
• 如果已提交用了不到分母的一半，硬错误/秒基本是 0，那你的机器压力很轻，把分页文件挪个位置或调小上限都可以从容操作。
• 如果 C 盘空间紧张，真正的元凶往往不是 pagefile.sys，而是 hiberfil.sys、Windows 更新缓存、WinSxS 组件库、还有各种开发工具的缓存目录。后面第 5 章会专门讲这个混淆。

这里补一个很多人不知道的坑：系统托管的分页文件在系统盘剩余空间不足时是长不起来的。Windows 会留一部分磁盘空间做保护，盘快满的时候分页文件就被卡在某个尺寸上不去，提交限制也就跟着封顶。所以你看到"内存还有 30% 空着却报内存不足"的诡异场景，根因往往是 C 盘快满了，而不是内存条不够。

2.2 删除或禁用它之后，链路会怎么断

"禁用分页文件"这个选项在界面上是能点到的，Windows 只会淡淡提醒一句"禁用分页文件后，将无法记录调试信息"，很多人直接忽略。实际后果按概率排序大概是这样：

第一层是应用层报错。一些程序启动时会一次性预留比较大的虚拟地址空间，比如大型 IDE、图像视频处理软件、数据库、JVM 系的应用。物理内存够，但提交上限不够，它们就起不来或者跑一半崩掉，报错文案五花八门，从"内存不足"到"无法创建临时文件"都有。

第二层是系统组件异常。Windows 的性能计数器、部分监控和诊断功能在完全没有分页文件的环境下会出现采集失败。如果你平时用工具盯着 CPU、磁盘、内存曲线，突然发现某些计数器读不出来了，先检查分页文件配置，而不是怀疑工具本身。

第三层是崩溃现场丢失。这一层平时看不出来，出事的时候才发现代价最大。

需要强调的是：在系统运行中直接删除 pagefile.sys 是删不掉的，文件被内核占用，会提示"操作无法完成，因为文件已在系统中打开"。有些教程教你用第三方工具强删或者进 PE 系统删，那纯粹是在制造隐患——文件删掉了，注册表里的配置项还在，系统下次启动发现配置指向的文件不存在，行为就变得不可预期。

2.3 "一键清理"类说法为什么不可信

网上流传的"三行命令释放 20GB 空间"这类内容，翻来覆去就是拿 pagefile.sys 和 hiberfil.sys 做文章，逻辑上有个共同漏洞：它们只统计了"能腾出多少空间"，从不统计"腾出空间之后拿什么换"。

一个典型的失真是把 SSD 寿命搬出来当理由，说分页文件读写会磨坏固态硬盘。这个说法在十年前机械盘时代有它的历史背景，但今天消费级 NVMe 固态的写入寿命（TBW）普遍在几百 TB 量级，而日常使用的分页写入量通常一年也就几 TB 到十几 TB，中间差着两个数量级。真正消耗写入量的是大文件拷贝、视频渲染、日志狂刷这些场景，不是分页文件。

另一个失真更隐蔽：把"关闭分页文件"和"关闭虚拟内存"混为一谈。虚拟内存是 Windows 内存管理架构的一部分，不因为你删了一个文件就消失；你删掉的只是它的一个落点，系统并不会因此变成"纯物理内存模式"，它只会变得更早开始拒绝内存申请。

提示：判断一个优化建议是否靠谱，就问一句"它付出什么代价"。只说收益不提代价的，基本可以直接跳过。

3. 合理做法：把页面文件放到正确的位置，设成正确的尺寸

3.1 三种配置模式怎么选

虚拟内存对话框里其实只有三个选择，很多人纠结半天，其实判断标准很清楚。

系统托管是最省心的模式，Windows 自己根据内存压力和磁盘空间伸缩。适用于绝大多数家用和办公机器，尤其是你不确定自己在干什么的时候。它的缺点是尺寸会变，C 盘空间紧张时容易被卡住，而且文件占用空间会随着使用习惯浮动。

自定义大小要你填初始大小和最大值两个数。适用于两类人：一类是 C 盘空间寸土寸金，想给它设个上限防止失控增长；另一类是想把分页文件整体挪到另一块盘上。设成固定值（初始 = 最大值）还有个附带好处，文件一次分配到位，之后不再变动，在机械盘上能减少碎片，在固态盘上则无所谓。

无分页文件正常情况下不该选。唯一的例外是你有明确的替代方案，比如把分页文件放到别的盘上、同时用专用转储文件接住崩溃转储，或者机器是一台纯粹的只读终端、跑的东西极其有限。

3.2 自定义大小该填多少

尺寸这件事，网上的说法从"内存的 1 倍"到"内存的 3 倍"都有，我觉得与其背倍数，不如按用途分档。核心原则只有两条：上限要留足，别绑死提交限制；系统盘上的分页文件要保证崩溃转储能落得下。

下面这张表是这些年实际用下来比较舒服的区间，不是绝对标准，按自己机器的负载微调即可：

关于崩溃转储的尺寸要求，可以记两个粗略门槛：完整内存转储需要在系统盘有一个不小于物理内存规模的分页文件（或者配置专用转储文件）；内核内存转储需要的空间小得多，通常留到物理内存的三分之一上下就够用。你可以在"启动和故障恢复"里看到当前选的是哪种转储类型，两边对齐设置就行。

我个人的常规做法是：16GB 内存的机器，系统盘给 4GB 初始、16GB 上限，用起来大多数时候实际只占用 2~4GB，峰值偶尔冲到 8GB 左右；同时把转储类型设成内核转储，兼顾空间和排查能力。

3.3 多盘机器上的放置策略

如果你机器上有两块盘，位置的选择会直接影响手感。

首选还是系统盘所在的固态盘。原因很实际：分页文件的读写是随机小块 I/O，机械盘在这种负载下延迟高得离谱，一旦发生硬错误，表现就是整个界面卡住几秒。把分页文件放在慢盘上，等于把内存压力的代价放大成卡顿。

第二块固态可以作为分担，但注意 Windows 会同时使用所有卷上的分页文件，并不会因为你放了两份就变成"备份"，它是按需分配负载的。两块盘各放一份，对机械盘混合配置的机器来说意义不大，反而增加了管理复杂度。

不要放在移动硬盘、网络盘、内存盘上。前两个是延迟问题，内存盘是逻辑问题——分页文件的角色是"物理内存不够时的落点"，你把它放进物理内存里，等于让备用金库也放在现金抽屉里，不但没有扩容，还白白吃掉一块内存，崩溃转储更是无从谈起。

3.4 关闭之前必须先确认的三件事

如果你确实有理由要关掉系统盘的分页文件，先过一遍这三项检查：

• 转储配置是否已经改了。到"启动和故障恢复"里把写入调试信息改成"无"，或者配置专用转储文件（注册表HKLM\SYSTEM\CurrentControlSet\Control\CrashControl下的DedicatedDumpFile与DumpFileSize），否则蓝屏之后你什么都没有。
• 是否有软件依赖内存预留。数据库、虚拟机平台、容器桌面端、部分游戏启动器都属于这个类别，先跑一遍你的日常软件清单再决定。
• 保留至少一份分页文件。就算系统盘不放，也要在其他固态盘上留一份，且上限别设得太小。

注意：修改为"无分页文件"之后，设置不会立刻生效，需要重启。重启之前文件还在，删除时提示被占用是正常的。

4. 完整实操链路：查看、迁移、验证、回滚

4.1 先用命令行把现状摸清楚

图形界面只能看到一个大概，命令行能看到实际分配值和峰值。管理员权限打开 PowerShell，依次跑这几条：

# 是否处于系统托管状态 Get-CimInstance Win32_ComputerSystem | Select-Object AutomaticManagedPagefile # 当前所有分页文件的位置、已分配大小（MB）、当前使用、历史峰值 Get-CimInstance Win32_PageFileUsage | Format-List Name, AllocatedBaseSize, CurrentUsage, PeakUsage # 注册表里保存的配置清单 Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management' ` -Name PagingFiles | Select-Object -ExpandProperty PagingFiles

PeakUsage这个值特别有用，它告诉你从开机到现在分页文件被用得最狠的一次是多少。连续观察几天，把峰值乘个 1.5 倍，基本就是你的合理上限，比拍脑袋填倍数靠谱得多。

再看一眼实时的提交情况：

Get-Counter '\Memory\Committed Bytes','\Memory\Commit Limit','\Paging File(_Total)\% Usage'

Committed Bytes除以Commit Limit就是提交使用率。这个比值长期高于 80%，说明你该加内存条了，调整分页文件只能缓解不能治本。

4.2 迁移到其他盘并让它生效

图形路径是：运行sysdm.cpl→ 高级 → 性能"设置" → 高级 → 虚拟内存"更改"。也可以直接运行SystemPropertiesPerformance.exe跳到性能选项。

操作顺序建议这样，别搞反：

1. 选中系统盘（通常是 C:），选择"自定义大小"，先填初始和最大值。
2. 选中目标盘（比如 D:，最好是另一块固态），同样设自定义大小，初始可以给小一点，上限给足。
3. 如果确实想让系统盘不再持有分页文件，选中 C: 再点"无分页文件"，点"设置"确认。
4. 一路确定，重启。

有个细节容易踩：改完每一条都要点一次"设置"按钮，只点"确定"退出的话，界面上的改动不会写进配置。改完之后用 4.1 里的注册表命令复查一眼，PagingFiles的值应该变成类似D:\pagefile.sys 4096 16384这样的形式，第一段是路径，后两个数字是初始和最大值。

4.3 验证是否真的按你设的走

重启之后别急着干别的，先复查三件事：

• 用Get-CimInstance Win32_PageFileUsage看AllocatedBaseSize是不是你设的初始值，路径对不对。
• 到目标盘根目录确认文件存在，系统盘上那个大文件是否已经不在了（如果设置了无分页文件）。
• 打开任务管理器看"已提交"的分母有没有变化。分母变大是一定的，如果没变化，说明配置没生效，回去查第 3 步。

然后正常用一两天，期间偶尔看一眼PeakUsage和硬错误/秒。如果峰值远低于你设的上限，说明设置偏保守但没问题；如果峰值贴着上限，把最大值再放宽一些。

4.4 万一出问题怎么退回去

回滚非常简单，这也是为什么我一直建议"先改位置再考虑减配置"。回到虚拟内存对话框，系统盘选回"系统托管"，其他盘设成"无分页文件"，重启，就回到了出厂状态。

有一类情况要注意：如果你在设置里把所有盘都设成了"无分页文件"，重启后系统可能仍然会创建一个小尺寸的临时分页文件来保证基本运行，也可能完全不创建，取决于版本和当前内存压力。这属于系统的自我保护机制，不代表你的配置生效了，遇到这种"半生效"状态，老老实实恢复系统盘的系统托管，别继续折腾。

5. 几个被反复误解的细节：SSD寿命、休眠文件、内存盘

5.1 固态硬盘的写入寿命焦虑，用错了地方

这个误解传播太广了，值得单独说。分页写入的量级和固态硬盘的寿命完全不在一个量级上，真正值得关心 SSD 寿命的场景是：频繁的大文件读写、持续的视频渲染、数据库高频写入、日志刷盘。分页文件在多数机器上一天也就写几个 GB，甚至更少，还有内存压缩在中间挡了一层——任务管理器里那个"内存压缩"进程就是干这个的，很多原本要落盘的内容被压缩后留在内存里了。

反过来说，把分页文件从固态挪到机械盘，换来的是更长的随机读延迟和更明显的卡顿。用体验换一个几乎不存在的寿命收益，这笔账不划算。

5.2 hiberfil.sys 和 pagefile.sys 不是一回事

C 盘根目录常见的两个大文件，一个hiberfil.sys，一个pagefile.sys，很多人把它们的处理方式混着用。

hiberfil.sys是休眠文件，用于休眠时保存整个内存镜像，同时 Windows 的"快速启动"功能也依赖它。它的大小通常接近物理内存的 40%~75%，所以在 16GB 内存的机器上它可能比分页文件还大。这个文件是可以关的：以管理员身份运行powercfg /h off，它就会消失，代价是失去休眠和快速启动，关机变成真正的完整关机。

注意区别：hiberfil.sys 关了基本不影响程序运行，只是启动稍慢一点、不能休眠；pagefile.sys 关了会直接影响应用能不能跑起来。想腾 C 盘空间，先动休眠文件，别动分页文件，这个顺序能省掉大量麻烦。

5.3 把页面文件放进内存盘是自相矛盾

内存盘（把一部分内存模拟成磁盘）是个很有意思的工具，用来放编译缓存、临时文件效果很好，但它不适合放分页文件。原因在 1.3 节讲过：分页文件是提交账本里"物理内存之外"的那部分，把它塞回物理内存等于账本自己给自己担保，提交限制并不会因为这份文件而增加，反而白白占用了一部分物理内存，还要额外承担内存盘驱动本身的稳定性风险。

同理，那些号称"把分页文件放到内存盘加速"的教程，实际效果通常是整体可用内存变少，遇到内存压力时崩溃得更早。

5.4 小内存机器跑容器和虚拟机的配置思路

现在开发机上跑 Docker 桌面端、WSL、本地虚拟机的场景很常见，这几类负载的共同特点是提交内存用量远超物理内存，因为它们启动时会预留大块虚拟地址空间。8GB 或 16GB 内存的机器上，这类负载最容易撞到提交上限。

我实际试下来比较舒服的搭配是这样：

• 分页文件留在系统固态盘，上限给足，16GB 内存的机器给到 24GB 上限都不算夸张。
• 内存压缩保持开启，别去找"关闭内存压缩"的教程，它会帮你省下不少落盘量。
• 容器和虚拟机的内存上限在配置里主动限制，别让它们无限申请。虚拟机的动态内存分配打开，容器的--memory参数按需给。
• 如果你经常同时开两个以上的虚拟机，优先考虑加内存条，而不是继续抠分页文件的尺寸。调整分页文件只能避免"报错"，缓解不了"卡"。

6. 四个真实案例的排查链路

6.1 案例一：内存占用才 70%，却弹内存不足

这是最典型的一类，也是最容易被误诊的一类。现象是物理内存使用率不高，但浏览器和编辑器同时弹内存不足。基本的排查链路是这样走的：

先看任务管理器的"已提交"，如果分母很小、分子贴着分母，第一层结论就出来了——问题在提交限制，不在物理内存。接着查分页文件的配置，多数情况下会看到三种情况之一：被第三方"优化"软件设成了很小的固定值；系统盘被设成了无分页文件；C 盘剩余空间不足，系统托管的分页文件长不起来。

第三种情况最隐蔽，因为配置看起来完全正常。验证方法是用命令行看AllocatedBaseSize是不是远小于你的物理内存，同时确认系统盘剩余空间。修复方式也很直接：清理系统盘腾出空间，或者把分页文件上限设成固定值并挪到空间充裕的盘上，重启后复查分母是否变大。

6.2 案例二：关掉分页文件之后，蓝屏没有转储可分析

这台机器是一台调试用的工作站，当时为了"减少硬盘写入"把系统盘的分页文件关了。后来出现一次蓝屏，事件查看器里只有一条重启记录，转储目录是空的，等于现场完全丢失。

这类问题的根因不是蓝屏本身，而是转储配置和分页文件的依赖关系断了。排查时先确认"启动和故障恢复"里的转储类型设置，再确认系统盘是否有足够大的分页文件或者专用转储文件。修复有两条路：一是恢复系统盘的分页文件并给足尺寸，二是保留关闭状态但配置DedicatedDumpFile，把转储写到另一个位置。两条路都能走通，关键是要明确选一条，而不是让系统处在"既没有分页文件也没有专用文件"的裸奔状态。

6.3 案例三：迁到机械盘之后整机反而更卡

这个案例的动机很朴素：听说固态盘写入量宝贵，就把分页文件迁到了机械盘。结果日常使用中出现一种很怪的现象——切回后台很久没动的程序时，整个界面会僵住一两秒，硬盘灯狂闪。

定位方式是打开资源监视器看"内存"标签里的硬错误/秒，同时看磁盘队列长度。如果硬错误发生时磁盘队列同时拉高，并且对应的是机械盘，结论就很清楚了：分页 I/O 落在慢盘上，延迟被放大成了肉眼可见的卡顿。

修复就是把分页文件挪回固态盘，机械盘那份直接设成无分页文件。迁回去之后卡顿现象消失，这也从侧面说明了一个事实：分页文件不只是在"内存不够"的时候才工作，日常调度里它一直在参与。

6.4 案例四：第三方优化工具留下的后遗症

这台机器的故事是同事跑了"一键优化"，工具顺手把分页文件设成了一个很小的固定值。表面上看 C 盘多了十几个 GB，实际用起来各种小毛病：性能监视器部分计数器读不出来，某个数据库客户端偶尔启动失败，日志里能看到内存分配相关的失败记录。

排查这类问题的关键是不要从症状二层往下追，先回到配置层核对。把分页文件的配置、转储配置、系统盘剩余空间三样东西对齐看一遍，基本一眼就能发现问题。修复方式就是把系统盘改回系统托管，同时把工具里其他"优化项"也复核一遍——这类工具通常不止改了一项。

我自己这些年折腾下来的几条经验

最后说点实际的。如果你想省 C 盘空间，动手顺序应该是：先关休眠文件释放 hiberfil.sys，再清 Windows 更新缓存和组件库，再考虑各类开发工具的缓存目录，最后才轮到分页文件，而且分页文件这一步优先做"迁移位置"和"设置上限"，不是"删除"。

如果你想判断自己该不该调整，最省事的办法是连续观察几天PeakUsage和提交使用率。峰值离上限很远，你随便怎么设都不太会出事；峰值贴上限，加内存条比改配置管用；提交使用率长期在 80% 以上，说明这台机器的负载已经超出它的配置了，再怎么调分页文件也只是把报错推迟一点。

还有一条很实用的习惯：每次改完虚拟内存配置，重启后花一分钟跑一遍第 4 章那三条命令，确认路径、分配值和提交分母三样东西都对上了。这个动作能挡掉绝大多数"以为改了其实没生效"的问题，包括那个经常被忽略的、改完不点"设置"按钮的情况。