一台机器的系统盘空间告急，你开始找"能删的大文件"。看到一个好几 GB 的页面文件，又查了查它的用量统计——峰值用量很低。于是结论很自然：这东西这么大却基本没用，删掉它，空间就回来了。这个结论，如果真执行了，很可能把某个应用推向崩溃。
现象
具体表现：
- 机器磁盘紧张，排查可回收空间；
- 发现页面文件（pagefile.sys）体积很大（好几 GB）；
- 用某个计数工具查页面文件的"峰值用量"，数值很低；
- 于是判断"它没被用上，是纯粹占地方"，打算删除或把大小调得很小。
这个判断链条看起来每一步都合理，但它的前提就错了。
根因
关键在于：那个页面文件，是另一个应用的"实际依赖"，而计数工具的"峰值口径"误导了这个判断。
先看页面文件是什么。它是操作系统在物理内存不够用时，把暂时不活跃的内存页"换出"到磁盘上的地方——本质是内存的溢出缓冲。当内存吃紧、有应用申请的内存超过了物理内存能容纳的量时，系统就靠它来顶住，避免直接失败。
那个计数工具报的"峰值用量"，通常指的是系统整体在某个统计窗口内、页面文件被使用到的最高值。这个口径有几个问题：
- 它可能只统计了系统自己的换页，没充分反映某个具体应用的占用；
- 它反映的是一段时间内的"最高水位"，而真正决定要不要保留的，是"如果拿掉它，最坏情况会不会撑不住"；
- 峰值低，不等于没用——平时用量低是正常的（内存够的时候不需要换出），但一旦内存压力上来，它就是那道最后的缓冲。把它撤掉，等于在最需要缓冲的时候把缓冲拿走了。
所以"峰值用量低"这个信号，不足以支撑"可以删除"的结论。判断该不该动它，要看的是"谁在用它、拿掉之后最坏会怎样"，而不是"它平时看起来用了多少"。
解决
结论是：这个页面文件要保留，不要纳入"可回收空间"。
正确的处理方式：
- 磁盘清理时把它排除在外。找可回收空间，从缓存、临时文件、日志、旧版本、装过的安装包这些真正的冗余入手，不要动页面文件。
- 如果内存确实吃紧，优先建议加内存，而不是去动页面文件。页面文件是"应急"用的，它能顶住瞬时峰值，但性能和内存差着数量级（磁盘换页远比内存访问慢）。真正的解法是让物理内存够用。
- 如果确实需要调整页面文件，也应该是充分评估之后的决定，而不是基于"峰值低"这一个数字。调整时通常保留系统管理的大小或一个不小于物理内存的合理值，而不是简单地删掉或砍到最小。
Windows 下查看页面文件的配置与用量的正确姿势：
# 看页面文件配置和实际用量（不是靠"文件有多大"来猜）
Get-CimInstance Win32_PageFileUsage |
Select-Object Name, AllocatedBaseSize, CurrentUsage, PeakUsage
# 看系统是不是让 Windows 自动管理
Get-CimInstance Win32_ComputerSystem | Select-Object AutomaticManagedPagefile
留意 AutomaticManagedPagefile：如果系统是自动管理页面文件，那手动去动它本身就是多此一举，还容易弄坏。
延伸与预防
这条坑的通用价值，是那句很值钱的话：磁盘清理建议要基于"谁在用它"，而不是"它看起来多大"。
清理磁盘时，很容易犯"以貌取物"的错：看着大、看着平时没用，就当成垃圾。但一个文件"大"和"没用"之间没有必然联系。判断能不能删，至少要回答：
- 谁在用它？它是不是某个功能的正常依赖（页面文件之于内存溢出、数据库的预分配文件之于性能、缓存目录之于命中率）？
- 拿掉它最坏会怎样？是"下次用时会重新生成"（可删），还是"直接功能失效/性能崩掉/数据丢失"（不可删）？
- 统计口径对不对？我看到的"用量低"，是不是因为统计的是错误的对象或错误的时间窗口？
这个思路不仅用于页面文件，也适用于数据库的 WAL/预分配文件、备份的保留副本、缓存的落盘目录、日志的历史归档。先问"它服务于谁、删了会怎样"，再决定动不动手。清理的目标是拿回冗余空间，不是拿回"看起来大"的文件——分不清这两者，就会在"清理"的名义下制造故障。前面"文件存在性检查"那条讲"查不到不等于没有"，这条讲的是它的镜像：看着没用，不等于没用。