前几天一个朋友在群里发了张截图电脑配置是 32GB 内存平时主要跑着 Docker Desktop、IDEA、Navicat外加一个 Elasticsearch 单机实例结果 Windows 突然弹出“系统内存不足”的警告随后 IDEA 直接卡死。群里几乎异口同声给出了建议——把虚拟内存调大。这个场景我在这些年里见过太多次了。问题在于很多人对虚拟内存的理解停留在硬盘划一块地方当内存用这个层面于是要么照着网上教程随手设了个 16GB要么干脆一不做二不休禁用掉。这两种做法在特定场景下都可能把系统搞得更糟。这篇内容我想做的事很简单把 Windows 虚拟内存涉及的底层机制讲清楚把网上流传的误区一个个拆掉再给出从诊断到配置、再到验证的完整路径。无论你是被 OOM 困扰的开发者还是想把手头电脑性能压榨到极致的重度用户这篇都值得花十分钟看完。1. 分页文件不是第二块内存先把底层机制拆开看1.1 虚拟地址空间到底是什么要理解虚拟内存必须先接受一个事实你写代码时拿到的那个地址从头到尾都不是真实的内存地址。现代操作系统Windows、Linux、macOS 都一样给每个进程分配了一个独立的虚拟地址空间。在 64 位系统上这个空间理论上是 16EB也就是 2 的 64 次方字节但 Windows 实际只实现到 128TB 用户态可用。这就是一个巨大的虚拟货架进程只管往这个货架上放东西、贴标签至于货架上的某个格子最终对应到哪根物理内存条、还是对应到磁盘上的某个文件、又或者根本就是个空壳由操作系统在幕后完成映射。这个抽象层解决了两个核心问题第一内存隔离——进程 A 完全看不到进程 B 的地址空间一个进程里出现野指针崩溃不会直接把另一个进程的数据踩烂第二物理内存超卖——多个进程分配的虚拟地址空间总和可以远大于物理内存的容量操作系统按需把真正用到的部分映射到物理页面上。打个比方物理内存是仓库里真实存在的货架虚拟地址空间是每个柜台手里的一本商品目录册。客户CPU来买东西时售货员MMU内存管理单元照着目录册查一下这个商品实际放在哪个货架然后去取。如果目录册登记了但货架上没有就得让库管操作系统内核去库房磁盘调货。1.2 分页文件在里面的真实角色那分页文件pagefile.sys在整个机制里的位置就很清楚了它是虚拟地址空间在磁盘上的后备存储。当物理内存吃不消时操作系统会把一部分暂时用不上的内存页腾到磁盘上腾出来的物理页面让给正在被频繁访问的数据。这个过程叫换出page out当 CPU 再次访问那些被换出的页面时再把它从磁盘读回物理内存叫换入page in。在 Windows 的性能计数器里对应术语叫硬错误Hard Fault——注意这和程序崩溃时的硬错误完全是两码事这里指的是页面不在物理内存、必须访问磁盘才能解决的缺页中断。判断内存压力的关键指标之一就是硬错误的发生频率。很多人有个误解以为虚拟内存等于物理内存不够时的救命稻草只有内存占满才启用。这个理解是错的。分页机制是持续运转的哪怕物理内存还有一大半空闲Windows 也会把一些很久没被访问的页面换出以维持足够多的空闲物理页面池子。这个池子有多重要当程序突然需要大量连续物理页比如启动大型应用、分配大数组时如果空闲页池太小操作系统就得临时去找哪些页面可以换出、然后执行换出操作这个连锁动作会直接表现为卡顿。所以你经常会看到一种现象任务管理器里内存占用才 50%但某个大程序启动时还是卡了好几秒很可能就是因为空闲页池不够深现换现用。1.3 物理内存很大为什么还需要分页文件这是被问得最多的问题我 32GB 内存平时都用不到一半虚拟内存还有啥意义直接禁用不行吗答案是不行而且有个非常实际的技术原因——内核态的内存需求不会因为你物理内存大就消失。Windows 内核在做驱动校验、生成崩溃转储蓝屏时的 dump 文件时默认都要依赖分页文件。你如果直接把分页文件禁掉系统虽然能跑但一旦发生内核模式崩溃就没有足够空间写完整转储之后排查问题会非常被动。另外很多第三方软件的行为是检查分页文件是否存在来决定是否启用某些功能而不是看物理内存总量。Adobe 全家桶就是典型例子有些版本如果检测不到分页文件会拒绝运行某些渲染任务或者直接崩给你看。所以结论很明确分页文件不能禁用但它的大小和位置确实值得手动干预。这也是本篇文章从原理落到实操的切入点。2. 关于虚拟内存的几个经典说法哪些该直接扔掉2.1 虚拟内存设置得越大越好大得没边会付出隐藏代价很多人设置虚拟内存时有一种心态既然怕不够用那就往死里调。4GB 物理内存设 16GB16GB 内存也设 16GB32GB 内存直接设到 64GB。这个思路有两个问题。第一个问题是磁盘空间占用。分页文件在默认配置下是动态伸缩的一个设置不当的最大值上限意味着在极端情况下它真的会吃满你预留的全部空间。系统盘一旦被 pagefile.sys 塞满你遇到的就不仅仅是内存问题而是一连串连锁故障Windows Update 装不上、临时文件写不了、某些数据库直接拒绝启动。第二个问题容易被忽略——大分页文件会影响休眠和快速启动的行为。Windows 的休眠模式hiberfil.sys和快速启动依赖在关机时把内核会话写入磁盘如果分页文件太大这部分 IO 耗时会变长。在某些配置下用户会感觉到点了关机后电源灯很久才灭这就是在写缓存。所以虚拟内存有一个合理区间超出这个区间不会带来额外收益只会白白消耗磁盘资源和 IO 带宽。2.2 放在 D 盘比 C 盘快这个结论是有前提的网上几乎每个教程都在说分页文件不要放 C 盘放到非系统盘这话只对了一半。微软官方文档里的说法是分页文件放在系统盘C 盘Windows 才能正常创建内核崩溃转储。如果你把分页文件完全移到 D 盘系统蓝屏时是找不到足够空间去写 dump 文件的。那放 D 盘更快的理论依据是什么呢有些人用机械硬盘HDD系统盘和应用都在 C 盘IO 已经相当繁忙把分页文件放到一块空闲的 D 盘确实能把页面换入换出的 IO 压力分摊到另一块物理磁盘上这是合理的。但如果你用的是单块 SSD把分页文件从 C 盘挪到 D 盘完全是多此一举因为物理磁盘就一块分区只是逻辑上的划分IO 负载并没有变化反而可能因为跨越分区边界带来额外的碎片问题。所以我的建议是单 SSD 用户默认保持 C 盘双硬盘用户SSD 做系统、HDD 做数据优先考虑在 SSD 上保留至少一个由系统管理的分页文件作为兜底然后把另一个分页文件放到 HDD 上作为补充。游戏加载地图、开发工具读取缓存这类大量随机读场景分页文件在 SSD 上的体验会好非常多。2.3 SSD 会被分页文件写坏损耗话题下的账本算术SSD 寿命恐惧症是个经久不衰的话题每次提到分页文件就有人说伤硬盘。咱们认真算笔账一个主流 512GB TLC SSD官方耐久度标称通常在 300 TBW总写入字节数左右。假设你的虚拟内存设置得很激进每天产生 50GB 的页面写入流量——这是非常夸张的场景了日常生活根本达不到——那么一年写入量大约 18TB这块 SSD 至少能扛 16 年。更何况分页文件的实际写入量远没有想象中那么大Windows 只会换出那些被修改过的脏页纯读取的映射页比如内存映射文件被换出后是可以直接从源文件重新加载的写盘根本不会发生。真正伤 SSD 的操作往往不是分页文件而是有些人为了加速去禁用 Windows Search、关掉 Defrag 计划任务、或者停用 Prefetch——这些骚操作带来的收益微乎其微反而让后台行为更不可预测。SSD 就是拿来读写的消耗品别把它供着。2.4 32GB 内存就不需要虚拟内存了内存碎片化了解一下内存碎片化是站在物理内存够大所以不需要分页文件这一派的对立面。设想一个场景你的系统里常年跑着十几个 Chrome 标签页、两个 IDEA 窗口、一个 SQL Server然后你打开 Word 想处理个文档。此时物理内存总量可能还有十几个 GB 的空闲但问题是这些空闲内存是碎片化的——分布在不同进程的保留区间之间无法直接提供给需要连续大块物理内存的操作。这个场景 Windows 几乎不会主动报内存不足但某些应用比如老旧的 32 位设计软件、某些控制软件在申请大块连续内存时就是会失败。分页文件存在时系统可以把一些低优先级进程的已修改页面换出到磁盘强行压缩出满足条件的物理页块从而避免这次申请失败。还有一个更硬核的技术点Windows 的内存压缩Memory Compression与分页文件是协同关系不是替代关系。从 1809 版本开始Windows 会把很多压缩后的页面存放在内存中的压缩存储区而不是直接写盘。这个机制降低了分页文件的读写频率但压缩存储区本身是有限的它更像是一层缓冲最终超压的部分仍然要落到 pagefile 里。物理内存再大也扛不住某些进程无上限的内存泄漏。3. 动手配置之前先判断你的内存不足是哪一种3.1 用性能监视器看内存压力而不是只看任务管理器任务管理器里的内存使用百分比只是一个非常粗糙的即时快照它看不到内存压力的动态趋势。判断系统是否真的处于内存饥饿状态建议打开 Windows 自带的性能监视器perfmon加入三组计数器观察计数器合理范围压力信号\Memory\Available MBytes长期大于物理内存的 20%持续低于 5% 且无回升\Memory\Pages/sec一般个位数到两位数持续高于几百说明频繁换页\Process\Working Set_Total与物理内存总量接近属正常加上分页文件使用量后仍持续大涨Pages/sec 这个指标要重点解释一下。它统计的是每秒硬错误加软错误的总次数其中软错误页面在内存中被重新分配基本无害真正需要关注的是硬错误。要单独看硬错误可以在性能监视器里加 \Memory\Hard Faults/sec。如果硬错误长期稳定在个位数说明内存调度非常健康如果经常冲到几十、上百就说明物理内存确实存在真实缺口此时调大分页文件才算击中痛点。否则就算你把它设成 100GB瓶颈依旧存在。3.2 事件查看器里的 OOM 蛛丝马迹光凭任务管理器你只能得知当前内存紧张却很难定位谁在紧张。Windows 在这件事上的记录其实非常完善。打开事件查看器eventvwr.msc展开Windows 日志 - 系统重点筛选来源为以下三类的记录Resource-Exhaustion-Detector事件 ID 2004Windows 内存资源耗尽检测器发出的窗口内内存不足警告。它会给出触发时的进程名和内存提交量同时指出哪个进程占用了最多已提交内存。Application Error事件 ID 1000应用崩溃记录很多 OOM 导致的进程被杀会在这里留下异常代码 0xC0000005非法访问或 0xC00000FD栈溢出。Windows Error Reporting事件 ID 1001包含错误模块路径、异常偏移对定位是否有第三方 DLL 干扰很有帮助。把事件 ID 2004 的历史记录拉出来看你会发现一个规律绝大多数内存不足事件主犯其实是那么一两个进程——Chrome 的渲染进程、Electron 应用、或者某个没有释放句柄的驱动。这比盲目调虚拟内存有意义得多因为如果是某进程在泄漏你调再大也一样会被吃掉。3.3 区分物理内存压力和虚拟地址空间耗尽这是很多开发者踩坑的重灾区。OOM内存溢出并非总是物理内存不足引起的。32 位进程默认只能看到 2GB 用户态虚拟地址空间即使系统有 64GB 物理内存、32 位程序启用了 LAA 大地址支持也通常只有 4GB所以一个 32 位进程哪怕物理内存还有很多富余它自己的虚拟地址空间也会被耗尽分配内存时直接抛 OOM。这事在旧版 Elasticsearch 上尤为常见——如果你用的是 32 位 JDK或者没做对 jvm.options 的堆内存配置明明机器内存很大ES 却频繁报 OutOfMemoryError。所以当你面对 OOM 时先回答两个问题第一报错的是哪个进程是操作系统层面的内存不足警告还是某个特定应用抛出的 OOM 异常第二这个进程是 32 位还是 64 位如果是 32 位进程配置 Windows 虚拟内存完全帮不上忙正确方向是换 64 位版本、给该进程开启 LAA、或者在现代 Windows 上依赖 WOW64 的地址空间重定位特性。如果是 64 位进程还在 OOM那才轮到分页文件配置登场。4. 手把手调整分页文件图形界面与命令行两条路径4.1 图形界面路径三步完成的分页文件设置现在进入实操环节。图形界面的路径是老生常谈但我觉得还是值得按 2025 年的系统界面重新写一遍因为 Windows 10 和 Windows 11 的设置菜单迭代过好几轮很多教程截图的入口已经找不到了按下 Win R输入 sysdm.cpl 并回车切换到高级选项卡。在性能区域点击设置再次切换到高级选项卡找到虚拟内存点击更改。取消勾选自动管理所有驱动器的分页文件大小。如果你的物理内存比较大16GB 以上可以先把自定义大小设到推荐的区间下文会细说或者保持系统管理的大小什么事都不做。点击设置保存重启系统。这里有个细节每一次修改分页文件后Windows 都会要求你重启才能完全生效。因为页面调度机制在系统会话开始时就初始化好了运行中途动态调整大小虽然能生效但涉及到分页文件扩展和收缩的安全边界调整某些内核组件如崩溃转储只有当分页文件在启动阶段就位时才具备完整功能。所以我建议但凡改完分页文件配置计划一个重启窗口别图省事。4.2 不同内存容量下的推荐参数区间设置多大合适没有绝对答案但结合微软官方建议和多年实践我整理了一个可以直接照抄的参考表物理内存分页文件初始大小分页文件最大大小适用场景4GB 及以下物理内存的 1.5 倍即 6144MB物理内存的 3 倍即 12288MB老机器、低压上网本8GB8192MB12288MB办公、轻度开发16GB8192MB16384MB日常开发、虚拟机轻度使用32GB4096MB12288MB重度开发、多虚拟机64GB 及以上4096MB8192MB工作站、视频渲染、大型编译注意看这个表和很多教程不一样的地方是内存越大初始大小和最大大小反而是下降趋势。原因很简单物理内存规模本身能覆盖大部分工作负载分页文件更多是兜底和兼容性角色。32GB 内存的机器去设置 64GB 分页文件纯粹是浪费磁盘空间。如果打开了内存转储需求、或者运行一些对内存提交量要求极高的应用比如某些 EDA 软件可以适当上调最大大小但初始大小保持在 4GB 到 8GB 已经非常健康。4.3 分页文件的自定义大小与系统管理到底怎么选微软默认的设置是自动管理所有驱动器的分页文件大小它由系统根据物理内存、页面提交量、应用负载动态伸缩。这个默认值其实很优秀微软在内存管理上积累的成果都在这套逻辑里。但为什么很多人还是喜欢手动指定因为自动伸缩有个微小但真实存在的问题当系统检测到内存压力、开始扩展分页文件时这个扩展动作本身是发生在高负载时期的会在本来已经很紧张的磁盘 IO 上再叠加一笔额外的分配开销极端情况下可能出现越卡越扩展、越扩展越卡的恶性循环。手动指定一个合适的固定大小可以消除这个扩展过程让分页文件的物理占用从一开始就达到足够大IO 行为也更稳定。这就是自定义大小的实际意义。不过请注意自定义不等于只设固定值。如果你取初始大小 8192MB、最大大小 8192MB就是完全固定如果初始大小 4096MB、最大大小 12288MB则是固定下限加动态扩展。在个人 PC 上我更推荐后者——没有高频 IO 争抢时用下限值省空间真要吃紧了还能弹性扩展。4.4 命令行配置适合批量部署的 PowerShell 方案如果你要给公司里几十台机器统一配置虚拟内存图形界面的效率太低了。用 PowerShell 调用 WMI 可以脚本化完成# 以管理员身份运行 # 将所有分页文件设置重置为由系统管理再为 C 盘设置自定义大小 $computers (PC01, PC02, PC03) foreach ($computer in $computers) { Invoke-Command -ComputerName $computer -ScriptBlock { # 取消自动管理 $sys Get-WmiObject Win32_ComputerSystem -EnableAllPrivileges $sys.AutomaticManagedPagefile $false $sys.Put() | Out-Null # 删除所有现有分页文件然后新建一个 C 盘的固定大小配置 $pagefiles Get-WmiObject Win32_PageFileSetting foreach ($pf in $pagefiles) { $pf.Delete() | Out-Null } Set-WmiInstance -Class Win32_PageFileSetting -Arguments { Name C:\pagefile.sys InitialSize 8192 MaximumSize 12288 } | Out-Null # 立即尝试刷新无需等待重启即可看到部分参数更新 Write-Output $env:COMPUTERNAME pagefile updated, reboot required to fully apply } }另一种写法是直接改注册表# HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management # PagingFiles 键值格式路径 初始大小 最大大小 # 例如C:\pagefile.sys 8192 12288 Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management -Name PagingFiles -Value C:\pagefile.sys 8192 12288 -Type MultiString两种方法二选一即可。注册表方式更底层WMI 方式更符合 Windows 管理规范。无论哪种都别忘记在调用后重启机器并确认页面文件设置生效。5. 开发与专业场景的虚拟内存专项配置5.1 Elasticsearch 的 OOM 与虚拟内存配置边界搜热词列表里有一批人是在折腾 Elasticsearch。ES 属于那种对内存极其敏感的开发中间件但它报 OOM 时调整 Windows 虚拟内存往往不是首选方案。原因在于 ES 基于 JVM 运行JVM 的堆内存只受进程自己的 Xmx 参数控制分页文件无法缓解 Java 堆的 OutOfMemoryError。如果 Xmx 给得太大超过了物理内存能提供的真实空间JVM 会发生 GC 抖动、频繁 Full GC、甚至整个进程被操作系统判极刑OOM Killer 或者直接异常退出。ES 场景下正确的虚拟内存相关操作是运行 bootstrap checks 时提示的max_map_count问题——在 Linux 上要调 vm.max_map_count这是内核参数。但 Windows 上没有直接对应项ES 的 bootstrap checks 里也没有针对 Windows 的 map count 检查。Windows 上跑 ES 真正容易出现的问题是mmap 文件映射的段映射数量限制表现为启动时报max file descriptors [4096] for elasticsearch process is too low——这也不是分页文件能解决的。所以我的结论是如果你的 Windows 上跑 ES 频繁 OOM优先检查 JDK 位数必须 64 位、堆内存配置建议不超过物理内存的 50%、以及是否需要限制搜索线程和聚合桶数量分页文件的调整可以做但要放在最后顺位。5.2 Docker Desktop / WSL2 的内存压力和 vmmem 进程搜索引擎里还有一堆人在问docker windows 内存不足。Docker Desktop 在 Windows 上用 WSL2 后端运行时默认会创建一个虚拟内存文件来模拟 Linux 的交换空间。这个虚拟磁盘文件ext4.vhdx会占用最多到 Docker Desktop 设置里分配的内存量。默认 Docker Desktop 会把 WSL2 总内存限制设为主机内存的 50%但很多人在设置里改内存限制时容易忽略一个硬约束WSL2 的交换文件是独立的它不依赖 Windows 的 pagefile。如果你给 WSL2 分配了 8GB 内存又分配了 2GB swap这 10GB 理论上限和 Windows 分页文件没有半毛钱关系。那为什么改 Windows 虚拟内存对 Docker 用户依然有意义因为 WSL2 的 vmmem 进程在宿主机上就是一个进程它的内存由 Windows 统一管理。当多个 WSL 发行版同时运行、Docker 容器数量增长时vmmem 的物理内存占用会上升这部分压力会传导到 Windows 的整体内存调度上。此时 Windows 分页文件的大小会影响系统能否优雅地扛过这个压力。我的建议是如果你频繁使用 Docker DesktopWindows 的分页文件至少保留 8GB 以上无论是系统管理还是自定义防止极端情况下 WSL2 与宿主机争抢内存导致系统僵死。同时把 Docker Desktop 的 Memory 限制设置在物理内存的 50% 以内留出余量给宿主机自身和 IDE。5.3 IDEA、Visual Studio、大型编译任务的内存分配IDE 和编译器是另一个内存大户。IntelliJ IDEA 在代码索引、Gradle/Maven 构建时会创建大量内存映射和缓存对象它的 JVM 堆内存默认值通常 2GB 起步不足以支撑大型工程需要手动调整idea64.exe.vmoptions。这里有个关键的交互逻辑JVM 堆的上限不能超过物理内存减去系统和 IDE 自身开销后的剩余量否则就是给后续的 OOM 埋雷。而 Windows 分页文件在这里的作用是缓冲池——当一个大型编译任务瞬间申请了超出空闲物理内存的堆外内存时比如 mmap 文件、JIT 编译器的代码缓存分页文件能提供一个临时空间让编译任务不至于被直接杀掉。Visual Studio 的 MSBuild 并发编译也类似。C 项目的并行编译会在短时间内分配大量堆内存。如果你经常做大型 C 编译建议把 Windows 分页文件设在 16GB 到 32GB 之间并且确保所在分区剩余空间充裕。否则你可能会遇到编译进行到一半突然报fatal error C1083或D8021这类看似文件打不开、实则内存不足以支撑编译器的错误。5.4 GPU 共享内存与显存不足的边界热词里还有不少人在搜gpu 虚拟内存——这个和 Windows 的 pagefile.sys 有一点点关系但机制完全不同。当显存VRAM不足时NVIDIA 和 AMD 驱动会使用共享 GPU 内存机制从系统物理内存中划出一部分作为显存的溢出区域。而这部分共享 GPU 内存的容量实际上受两个因素限制驱动设定的最大值通常等于物理内存的一半以及 Windows 分页文件的剩余空间。当物理内存本身也被占满、分页文件又不够大时某些图形应用比如本地跑 Stable Diffusion、视频渲染就会报CUDA out of memory或DXGI_ERROR_DEVICE_REMOVED。这里有一个实际的调优路径如果你的工作负载需要频繁使用 GPU 大显存把 Windows 分页文件设置在系统盘并留出至少物理内存 25% 的空间会给驱动的共享内存能力留出余量。别把分页文件完全禁用否则某些驱动函数调用会直接失败。不过也要清醒一点共享 GPU 内存的性能远不如真正的显存它只是兜底方案。如果你的工作负载稳定超过显存容量正确的做法是换更大显存的显卡或降低分辨率/模型规模而不是靠虚拟内存硬扛。6. 配置之后还要会验证别让调整变成自我安慰6.1 确认分页文件真正生效的两种方法一般人在设置界面看到路径和大小数字就以为配置好了。但 Windows 存在一种设置保存了、系统没采用的情况尤其在多块硬盘、权限异常、或者被组策略锁定的环境里。所以配置完成后要验证。第一种方式最简单任务管理器 - 性能 - 内存看已提交区域或者用系统信息面板分页文件大小。但这个只能看到汇总。更精确的方式是用 PowerShell 查询Get-CimInstance Win32_PageFileUsage | Select-Object Name, AllocatedBaseSize, CurrentUsage, PeakUsage如果AllocatedBaseSize显示的值和你设置的初始大小一致说明系统已采用如果CurrentUsage持续逼近AllocatedBaseSize说明分页文件可能不够大需要加大。另外用Get-CimInstance Win32_PageFileSetting可以看到配置的初始大小和最大大小两相对比就能确认配置是否完整生效。还要注意一种特殊状态当你的初始大小和最大大小设置相同完全固定系统会一次性分配完整文件磁盘上立刻出现对应大小的 pagefile.sys如果设置了不同的初始和最大大小初始阶段 pagefile.sys 是稀疏文件占用磁盘空间小于最大值这是正常的不是配置失败。6.2 调完虚拟内存还是频繁 OOM五个排查方向这是最让人沮丧的情况——明明把分页文件从 4GB 调到了 32GB问题依旧。如果发生这种状况请按顺序排查以下五个方向而不是继续加大分页文件第一是不是 32 位进程的虚拟地址空间耗尽。用任务管理器 - 详细信息添加程序类型列把出问题的进程标为32 位的话优先换 64 位版本或启用大内存地址。这一步和 Windows 全局虚拟内存设置无关。第二是不是有内核态内存泄漏。有些第三方驱动尤其是老版本网卡驱动、杀毒软件的过滤驱动、虚拟化平台代理会在内核池中持续泄漏非分页内存。用 PoolMonWindows 驱动工具包自带能看到非分页池的字节数趋势。正常空闲状态下这个数值应该稳定持续上涨说明有泄漏。第三是不是提交量本身超标。任务管理器 - 性能 - 内存看提交部分的峰值。如果提交峰值已经超过物理内存 分页文件的上限说明系统设计的已提交内存空间不足。这种情况需要看是否有某进程创建了巨大的虚拟内存保留区比如早期 Firefox 的 bug而不只是会话内存不足。第四是不是存储 IO 成了瓶颈。分页文件扩容了但换页速度取决于磁盘速度。如果分页文件所在磁盘随机读写速度非常慢比如一块 5400 转机械盘系统可能依然表现为卡死式 OOM——因为页面换入的速度赶不上 CPU 的请求。把分页文件挪到 SSD比一味增加大小有效得多。第五是不是应用自身的 OOM 与系统无关。Elasticsearch、Java 应用、Node.js 的 OOM 是进程内堆内存耗尽Windows 分页文件再大也救不了。查 JVM 的 -Xmx、Node 的 --max-old-space-size方向完全不同。6.3 如何把配置迁移到新电脑/重装系统之后最后分享个实用技巧每次配置好分页文件后把关键信息保存成一个文本或注册表导出方便重装系统后快速恢复。我自己的做法是写一个一键脚本# 保存当前配置 reg export HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management C:\Backup\mem_mgmt.reg # 重装后恢复 reg import C:\Backup\mem_mgmt.reg但注意这个注册表键里还包括了 ClearPageFileAtShutdown、DisablePagingExecutive 等多种设置如果只是改分页文件手写一个配置脚本更干净。把第 4.4 节里的 PowerShell 脚本存成 ps1 文件重装后右键使用 PowerShell 运行30 秒就能恢复一套完整配置。把分页文件设置固化成基础设施清单的一部分比每次都在图形界面里翻来翻去省事得多。回到文章开头那个朋友。他真正的问题不是虚拟内存不够而是 Docker Desktop 的 WSL2 内存限制没有配置、IDEA 堆给到了 8GB、ES 堆又给了 6GB——三座大山叠加32GB 物理内存根本扛不住。我让他把分页文件固定到 8GB~16GB、把 WSL2 内存上限调到 12GB、IDEA 堆降到 4GB之后重启再也没出现过内存不足。这说明一个很朴素的道理虚拟内存是系统资源调度的最后一道缓冲而不应该成为你忽视真实内存分配现状的借口。把分页文件配置到健康区间再把那些内存大户的设置各自理顺OOM 才能真正远离你。希望这篇从原理到实操的梳理能帮你一次性把这些概念捋顺。