从 8.86 GB 到 39 GB：我把一台 Win11 笔记本的 C 盘救回来了

发表于 更新于 分类于

一台两年的 Win11 笔记本，C 盘 119 GB 只剩 8.86 GB，比 7% 还少。
三阶段、两个坑，最终腾到 39 GB（33%）——4.4× 提升。
这是完整的清理手记，含关键技术点、脚本片段和踩坑复盘，发出来希望能帮到同样手忙脚乱的人。

TL;DR

指标 优化前 优化后
C 盘总量 119 GB 119 GB
已用 110 GB 80 GB
可用 8.86 GB（7.4%） 39 GB（33%）
警告线（10%） 已触线 安全

三阶段释放构成

阶段 内容 风险 释放
阶段 0 浏览器/办公/IDE/AI 工具缓存 零（备份可回滚） ~11 GB
阶段 1 系统还原、WinSxS、WDAG、pagefile、事件日志 低（需管理员） ~13 GB
阶段 2 用户级 Python 包、AI 工作区、VS/SDK 迁移 中（迁错可回滚） ~8 GB

一、先看体检报告

动手前先扫一遍状态。我用了 PowerShell + Bash 的混合脚本，只读不写：

1
2
3
4
5
6
C 盘总量       : 119 GB
已用           : 110 GB
可用           : 8.86 GB      ← 触线，低于 10% 警告阈值
D 盘           : 148 GB，几乎空
E 盘           : 428 GB，几乎空
物理内存       : 15.9 GB（峰值使用仅 ~1 GB）

症结很明显：数据全都堆在 C 盘，D/E 盘空着没人用。最直接的修法是”先备份后删除” + “把可外迁的应用迁出去”。于是我定了三阶段路线图，每个阶段都能停下来观察、能回滚。

二、阶段 0：缓存清理（~11 GB）

最稳的肥肉是各路缓存。清单：

  • Chrome 模型缓存：2.67 GB
  • 钉钉缓存：~2.3 GB
  • WPS 残留：~2.7 GB
  • 微信插件：0.41 GB
  • 回收站：5.41 GB（单独拎出来清，下面会讲为什么）
  • Gradle / pnpm / npm / pip 包管理器缓存：合计 ~1 GB

关键技术：robocopy 备份 + 返回码校验

每个目标走同一套流程：

1
2
3
4
5
6
7
8
# 1) 备份到 E 盘
robocopy "" "\" /E /COPY:DAT /R:1 /W:1 /NP /NFL /NDL

# 2) 校验返回码
# 0 / 1  = 成功；>= 8 = 出错（中止删除）

# 3) 删除原目录
Remove-Item "" -Recurse -Force

阶段 0 的两个坑

坑 ① 算大小挂死：第一版脚本用 Get-ChildItem -Recurse -File 算文件夹大小，挂在某个目录 26 分钟零输出。教训是——robocopy 直备不需要算大小，返回码就是校验结果。

坑 ② 漏了回收站：阶段 0 跑完，C 盘反而”变小”了。根因是脚本漏了 Clear-RecycleBin，且用户会话期间回收站又涨了。清单里必须单列回收站。

回收站单独清一行就够：

1
Clear-RecycleBin -DriveLetter C -Force

三、阶段 1：系统级优化（~13 GB）

这一步需要管理员权限，每个子项可以独立开关。

A. 系统还原影子存储上限 → 3 GB（释放 ~8 GB）

Windows 默认把 10%+ 空间预留给”系统还原影子副本”，日常根本用不上那么多。

1
vssadmin Resize ShadowStorage /For=C: /On=C: /MaxSize=3GB

B. DISM WinSxS 清理 + -ResetBase（释放几百 MB ~ 几 GB）

1
dism /Online /Cleanup-Image /StartComponentCleanup /ResetBase

-ResetBase 会让系统无法再卸载旧更新，但能多清一些。前提是你这台机器已经稳了至少半年。

C. WDAG 容器镜像删除（3.94 GB）

Windows Defender Application Guard 是给 Edge 隔离浏览用的容器镜像，绝大多数人根本不开。如果你不用 Edge 隔离，直接清：

1
2
3
4
5
# 1) 卸载功能
dism /Online /Disable-Feature /FeatureName:AppHVUI -Remove

# 2) 清缓存
Remove-Item "C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\Cache" -Recurse -Force

D. 事件日志清空（释放几十 ~ 几百 MB）

1
2
3
wevtutil cl Application
wevtutil cl System
wevtutil cl Security

E. 页面文件：2 GB 固定（释放 ~5 GB）

观察到 pagefile 峰值只 ~1 GB，于是设成 2048 MB 固定：

1
2
3
4
5
$cs = Get-CimInstance Win32_ComputerSystem
$cs | Set-CimInstance -Property @{ AutomaticManagedPagefile = $false }

Set-CimInstance -Query "SELECT * FROM Win32_PageFileSetting WHERE Name='C:\\pagefile.sys'" `
    -Property @{ InitialSize = [uint32]2048; MaximumSize = [uint32]2048 }

坑 ③ CIM 类型不匹配：第一次脚本传 2048 报”类型不匹配”。CIM 属性是 uint32，PowerShell 默认 int32，必须强转 [uint32]2048。这个坑我们后面会再踩一次反作用。

NVIDIA 旧驱动：建议保留

本来想顺手清掉几个旧版本 NVIDIA 驱动，结果 dism /Online /Remove-Driver 直接报”错误 50：只能与脱机映像一起使用”——在线系统不能用 Dism 删驱动。Installer2 缓存 223 MB 我顺手清了，驱动本体保留。要清驱动请用 DDU 离线模式。

四、阶段 2：用户数据迁移与清理（~8 GB）

删除部分（~3 GB）

  • Python 用户级包（torch / PyQt）：0.84 GB
  • AI 工具 node_modules（两个工作区）：2.31 GB

先备后删，备份目录按日期归档，回滚无忧。

迁移部分（~5.87 GB）：junction 透明重定向

把 VS 生成工具、SDK、VS Installer Package Cache 搬到 E 盘，C 盘留 junction 透明重定向：

1
2
3
4
5
6
7
8
9
10
11
# 1) 复制到 E 盘
robocopy "C:\Program Files (x86)\Microsoft Visual Studio" `
         "E:\relocated\Microsoft Visual Studio" /MIR /COPY:DAT

# 2) 原目录改名做安全网（不删！）
Rename-Item "C:\Program Files (x86)\Microsoft Visual Studio" `
           "C:\Program Files (x86)\Microsoft Visual Studio.relocated"

# 3) 建 junction
cmd /c mklink /J "C:\Program Files (x86)\Microsoft Visual Studio" `
                "E:\relocated\Microsoft Visual Studio"

三个目标都一样处理：VS、SDK、Package Cache。

关键安全网：原目录改名不删，叫 *.relocated。如果 VS 出问题，可以瞬间回滚（删 junction + 删改名后缀）。观察几天没问题再单独跑 p2_cleanup.ps1 释放安全网。

迁移完成后 C 盘立刻多出 5.87 GB——junction 本身只占几个字节。

五、踩坑复盘：pagefile 干翻 Hyper-V

阶段 1 全跑完的第二天早上，开机发现 13.4 GB 内存的 Linux VM 启不来：

1
2
"无法分配 13394 MB 的 RAM"
错误码：0x800705AA (ERROR_NO_SYSTEM_RESOURCES)

这一路我走了三轮才彻底修好，每一轮的错误码都是进步信号：

错误码 含义 这一轮做了什么
0x800705AA 系统提交预算不足 脚本把 pagefile 改成”系统托管”，重启
0x8007000E 物理内存真的不够 脚本把 VM 改成 Dynamic Memory
InvalidState VM 还在”已保存”状态，Hyper-V 锁内存配置 脚本先 Stop-VM -Force 再 Set-VMMemory

根因复盘

这台机器 16 GB 物理内存，VM 想要 13.4 GB 固定 RAM。13.4 + 主机 ~3 + Hyper-V 开销 ~1 = 17.4 GB > 16 GB，物理上装不下，跟 pagefile 大小其实无关。

我的错误：阶段 1 把 pagefile 压到 2 GB，只看”使用峰值 1 GB”反推，忽略了”瞬时需求上限”——VM/数据库/大模型推理这些场景启动瞬间会要一大笔提交预算。

教训清单

  1. 资源上限类优化不能只看使用峰值，要先列出会被影响的典型负载（VM、数据库、大模型、视频剪辑……）
  2. 关键优化跑完主动做一次回归问询——“这次清理有没有把什么跑不起来？”，不要等用户当发现问题的第一人
  3. Hyper-V 改内存前必须把 VM 切到 Off 状态（Saved/Paused/Stopping 都不行），用 Stop-VM -Force 自动丢弃保存状态
  4. 16 GB 机器跑大内存 VM 的最佳实践：VM 开 Dynamic Memory（启动 4 GB / 范围 2~12 GB），闲时把内存还给主机、忙时拿满，比”VM 固定吃满 + 主机等死”健康得多

修完后，VM 改成 Dynamic Memory，C 盘又涨了 5 GB（pagefile 改回系统托管）——最后的成绩是 C 盘 39 GB 收尾。

六、最终成绩单

1
2
3
4
5
6
7
阶段          释放            关键项
─────────────────────────────────────────────
阶段 0        11 GB           回收站 5.41 + 各类缓存
阶段 1        13 GB           系统还原 ~8 + WDAG 3.94 + pagefile ~5
阶段 2        8 GB            AI 工作区 3.15 + VS/SDK 迁移 5.87
─────────────────────────────────────────────
合计          ~32 GB

C 盘最终：8.86 GB → 39 GB（33%），4.4× 提升。

七、给同样手忙脚乱的人

  1. 先看体检报告再动手——别上来就清缓存，先 Get-PSDrive / du -h 摸清楚大块在哪
  2. 三阶段路线图：零风险 → 系统级 → 结构性迁移，每阶段都能停
  3. 备份 > 删除——robocopy + 改名 .relocated 安全网 > 直接 rm -rf
  4. junction 迁移比”删了重装”温和得多，尤其是 VS、SDK 这类对路径敏感的应用
  5. pagefile 不能拍脑袋压——先看这台机器跑什么负载
  6. 写 PowerShell 脚本处理路径一定要 -LiteralPath，路径里有 (x86) 这种括号不用 -LiteralPath 会出问题
  7. CIM 数值属性必须强转 [uint32]，默认 int32 一定踩坑
  8. 交付给用户用 powershell -File 跑的脚本，用 UTF-8 BOM + 纯 ASCII，避免本地 ANSI 编码解析失败
  9. Dism /Online /Remove-Driver 在线系统受限，要清驱动请用 DDU 离线模式

附录：本文用到的脚本

脚本 用途 权限
Stage1_SystemCleanup.ps1 阶段 1 主脚本（A 还原 / B pagefile / C WinSxS / D NVIDIA / E WDAG / F 日志） 管理员
p1_fix_pagefile.ps1 pagefile 修复（含 [uint32] 强转） 管理员
p1_fix_pagefile_hyperv.ps1 pagefile 恢复 + 系统托管选项 管理员
p2_migrate.ps1 VS / SDK / Package Cache 迁移（robocopy + junction） 管理员
p2_cleanup.ps1 删除 *.relocated 安全网（先校验 junction） 管理员
p1_fix_kali_vm_memory.ps1 Hyper-V VM 内存修复（先 Stop-VM -Force 切 Off） 管理员

全部脚本遵循同一原则：先校验、再操作、操作完再校验。

标签：#Windows #C盘优化 #Hyper-V #Junction迁移 #Pagefile #PowerShell