不安全——自动管理易致蓝屏或内存溢出，因忽略峰值负载与SSD碎片；应手动设置分页文件，禁用自动管理，合理分配大小并置于NVMe或SATA SSD，不可关闭或放于HDD、加密卷、RAMDisk。
Windows虚拟内存分页文件设成“自动管理”真的安全吗
不安全——尤其在内存吃紧、频繁运行大型程序或虚拟机时。自动管理常把分页文件压到最低（比如仅 1–2 gb），导致 0x0000001a（memory_management）蓝屏或 out of memory 异常。它只看当前物理内存占用，不预估峰值负载，也不考虑页面文件碎片化对 ssd 寿命的影响。
实操建议：
- 禁用
自动管理：右键“此电脑”→“属性”→“高级系统设置”→“性能”设置→“高级”→“虚拟内存”→取消勾选“自动管理所有驱动器的分页文件大小” - 若物理内存 ≤ 16 GB，建议手动设定初始值 = 物理内存 × 1.5，最大值 = 物理内存 × 3；≥ 32 GB 可设为“初始=物理内存，最大=物理内存 + 4096 MB”
- 不要把分页文件放在系统盘以外的机械硬盘上——随机读写延迟太高，反而拖慢
pagefile.sys响应
为什么不能把分页文件设成“无分页文件”
即使你有 64 GB 内存，关掉分页文件仍会触发大量兼容性问题：Windows Error Reporting、WERFault.exe 无法生成 dump；某些驱动（如 NVIDIA 显卡驱动）强制依赖 pagefile.sys 存在；部分 .NET 程序调用 VirtualAlloc 时默认要求后备存储，缺页文件直接返回 NULL 导致崩溃。
关键点：
-
pagefile.sys不只是“内存不够时的备用”，更是 Windows 内存管理器的强制后端存储（commit charge 机制） - 完全禁用后，任务管理器“提交”值上限 = 物理内存，但很多程序按“可提交总量”分配地址空间，容易触发
ERROR_COMMITMENT_LIMIT - SSD 寿命不必过度担忧：现代 NVMe 的 TBW 足够支撑数年常规分页操作，反倒是频繁内存耗尽导致的硬重启更伤硬件
多硬盘环境下分页文件该放哪个盘
优先放与系统盘同型号、同通道的 NVMe SSD 上；若只有 SATA SSD + HDD 组合，宁可放在 SATA SSD（哪怕它是 D: 盘），也不要跨到 HDD。Windows 不支持分页文件跨盘冗余，但支持单盘多文件——不过没实际收益，反而增加元数据开销。
注意细节：
- 避免放在 BitLocker 加密卷（尤其是启用了
TPM + PIN的系统启动盘），否则休眠恢复时可能因解密延迟导致pagefile.sys访问超时 - 不要放在被第三方工具（如
PrimoCache或FSRM）挂载为 RAMDisk 的盘符上——这类盘符在启动早期不可写，系统可能静默降级为无分页文件 - 如果使用 Intel RST 或 AMD StoreMI 的缓存加速盘，确认
pagefile.sys所在分区未被设为“仅缓存读取”模式，否则写入会失败
修改后要不要重启？怎么验证生效
必须重启。Windows 在登录前就完成分页文件初始化，热修改只影响下次启动。验证是否生效，别只看“属性”窗口，要查真实状态：
打开管理员权限的 PowerShell，运行：
Get-CimInstance -ClassName Win32_PageFileUsage | Select-Object Name,CurrentUsage,PeakUsage,AllocatedBaseSize
重点关注 AllocatedBaseSize（单位 MB）是否匹配你设置的初始值；CurrentUsage 非零才说明系统真正在用它。
常见误判点：
- 资源监视器里“内存”页签的“提交限制”数值 ≠ 分页文件大小，它是“物理内存 + 所有分页文件总和”，容易高估
- 用
wmic pagefile list /format:list查到的是配置项，不是运行时状态；得用Win32_PageFileUsage类才能看到实际占用 - 某些杀毒软件（如 Kaspersky）会在启动时锁定
pagefile.sys，导致修改后首次重启仍沿用旧大小——此时需进安全模式再设一次
最麻烦的其实是混合内存场景：比如插了 Optane Memory 作系统加速，或者用了 Windows Subsystem for Linux 2（WSL2）的动态内存分配，这些都会干扰 commit charge 计算逻辑，分页文件大小得比标称值多留 2–4 GB 缓冲。
