内存占用过高会触发Windows OOM机制，导致进程终止、响应停滞或MEMORY_MANAGEMENT蓝屏；真正致命的是内存泄漏叠加内存条兼容性问题，需通过已提交内存、可用内存、MemTest86硬件检测等综合排查。
内存占用过高本身不会直接“死机”，但会触发 Windows 的 OOM（Out of Memory）机制，导致进程被强制终止、系统响应停滞，或在物理内存+页面文件耗尽时蓝屏（如 MEMORY_MANAGEMENT、PAGE_FAULT_IN_NONPAGED_AREA）。真正致命的往往是内存泄漏叠加硬件级兼容性问题——比如某根内存条在高负载下出现位翻转，而系统还在拼命往里塞数据。
查清是泄漏还是真不够用
任务管理器里看到内存使用率长期 >90%，不能直接断定“要加内存”。先看“已提交”和“可用”两个关键值：已提交远超物理内存总量（比如 32GB 物理内存，已提交显示 48GB），说明系统在靠页面文件撑着；如果 已提交也逼近上限，才是真缺资源。而如果 可用始终只有几十 MB，但 已提交稳定在合理范围（如 25GB/32GB），大概率是某个进程在泄漏——比如 chrome.exe 打开 20 个标签后内存不释放，或 explorer.exe 关联的 DwmCore 服务持续涨到 1.5GB 以上。
- 右键
dwm.exe→ “转到服务”，临时停止DwmCore观察是否缓解 - 在“详细信息”页按
内存排序，留意随时间持续上涨的进程（不是瞬间峰值） - 避免只看“工作集”，重点盯
提交大小列（需在“选择列”中勾选）
禁用 SysMain 和 Print Spooler 这两个高风险服务
SysMain（原 Superfetch）在 Win10/Win11 中对 SSD 优化失效，反而会在后台预加载大量数据进内存，且极少释放；Print Spooler 则存在多年未修复的句柄泄漏，在有网络打印机或 PDF 虚拟打印机的环境中极易缓慢吃光内存。两者都不是“可选服务”，而是默认开机自启并长期驻留。
- 运行
services.msc，找到SysMain和Print Spooler - 双击→启动类型设为“禁用”，点击“停止”
- 重启后观察内存增长曲线是否变平缓（可用 Resource Monitor 实时跟踪）
别关 pagefile.sys：手动设静态虚拟内存更稳
即使你装了 32GB 内存，关闭 pagefile.sys 仍可能引发崩溃。微软明确警告：关闭它会让系统内存“提交限额”直接卡在物理内存容量以下，导致程序申请内存时被拒绝——哪怕物理内存还有空闲。正确做法是把虚拟内存从“自动管理”改成手动设定，并迁出 C 盘。
- 运行
systempropertiesadvanced→ 高级 → 性能“设置” → 高级 → 虚拟内存“更改” - 取消“自动管理所有驱动器的分页文件大小”
- 选 C 盘 → 选“无分页文件” → “设置”；再选另一块 SSD（如 D 盘）→ “自定义大小”，初始=物理内存，最大=1.5 倍（例：32GB → 初始 32768，最大 49152）
- 重启生效。此时
pagefile.sys只存在于 D 盘，C 盘压力降低，且提交限额不再受制于 C 盘碎片或空间不足
MemTest86 是唯一可信的内存硬件验证方式
Windows 内存诊断工具（mdsched.exe）只能做基础 CRC 检查，对时序错、电压不稳、XMP 冲突等真实兼容性问题完全无感。很多用户跑完 Windows 自带工具说“没报错”，结果一开 Chrome+VM 就画面定格——那是因为错误发生在特定访问模式下，只有 MemTest86 的多模式压力测试能暴露。
- 必须单根内存测试：拔掉其他所有条，只留一根插在主板标注的 A2 槽（首选通道）
- 用 Rufus 将 MemTest86 ISO 写入 U 盘，UEFI 启动，选 “Test all RAM”
- 至少跑满 4 轮（约 40 分钟），出现任何红色
Error行即判定该条不可靠 - 若某根通过，换下一根重复；全部通过，再测双通道组合（此时才启用 XMP）
最容易被忽略的是 SPD 缓存残留：换新内存后 BIOS 可能仍沿用旧条的时序参数，导致隐性不稳定。重置 BIOS 设置（Load Optimized Defaults）比单纯关 XMP 更彻底；若主板支持，进 BIOS 找 “Refresh SPD” 或 “Re-read SPD” 选项手动触发一次，才能让新内存真正按标称规格运行。
