前几天早上我刚打开电脑微信就开始弹“存储空间不足”我心想坏了。一看C盘剩余空间不到300MB系统分区直接红得发黑。这种时候最容易干蠢事——打开各种“清理大师”一键狂删或者对着C盘目录瞎猜删了不该删的把软件搞坏。这次我没急着动手而是让 Codex 来帮我做了一次完整的磁盘体检。最终我定位到 AppData 目录占了 87.81GB并且在没有误伤任何软件配置的前提下安全释放了大约60GB的空间。这篇文章就是这次排查的全过程记录。我会把 AppData 为什么会膨胀到这种程度、我为什么用 Codex 而不是传统扫描工具、具体的排查命令和判断逻辑以及最后的删与不删、如何防止下次再爆红一条条讲清楚。适合C盘常年告急、又不敢乱动文件的人尤其是装了各种开发工具、浏览器、虚拟机的人。1. AppData 这个“黑洞”为什么能吞下 87.81GB1.1 先搞清楚 AppData 到底是什么AppData 是 Windows 给每个用户单独划分的一块应用程序数据目录默认是隐藏的。你在资源管理器地址栏输入%LOCALAPPDATA%、%APPDATA%就能看到它。它下面有三个子目录分工完全不同Local本机专属的重缓存数据比如下载缓存、临时文件、软件更新包、虚拟磁盘文件都在这。这是膨胀的主力空间占用通常最大。Roaming可以跟着账户漫游的数据主要是各种软件的配置、登录态、历史记录。看起来不大但日积月累也很可观。LocalLow低权限进程用的数据区域浏览器插件、某些游戏组件会写在这里一般占不了太大空间。如果用生活化的类比AppData 不是“垃圾场”更像是家里那个杂物间里面有日常要用的工具箱也有积压很久的快递纸箱。你看着乱但不能因为乱就全扔得先分清哪个是能重建的缓存、哪个是不可重建的配置。很多人一看C盘满了就冲进 AppData 乱删结果最常见的两种悲剧一是把软件配置删了软件打开跟新装的一样登录态全丢二是删掉了正在被占用的文件导致软件崩溃甚至系统组件异常。所以我一直坚持的原则是先定位再判断最后动手。1.2 空间守恒凡是缓存必有来源我特别喜欢一个说法磁盘空间是守恒的每个大文件都有它的“生产者”。如果能回答“谁创建了它”基本就能回答“能不能删它”——因为缓存类的东西删了会自动重建配置类的东西删了就真没了。87.81GB 这种量级的 AppData通常不是某一个大文件单独造成的而是好几个“大户”联手。我自己这次最典型的构成大概是这样的目录典型占用范围来源WSL2 的 ext4.vhdx 虚拟磁盘10~60GBLinux 子系统里的软件包、日志、容器镜像包管理器缓存npm/pnpm/pip/Yarn3~30GB下载过的依赖包压缩文件用于离线加速安装Temp 临时目录2~15GB软件安装包、解压临时文件、崩溃转储浏览器用户数据与缓存3~20GB网页缓存、Cookie、扩展、媒体文件显卡着色器缓存DXCache/GLCache1~8GB游戏和图形程序运行时生成的着色器汇编结果Electron 应用的逐个项目缓存1~5GB聊天软件、文档工具等基于 Electron 的软件自带一个浏览器内核这里要特别说一下 WSL2。如果你装了 Windows 的 Linux 子系统整个 Linux 文件系统其实被塞进一个叫ext4.vhdx的虚拟磁盘文件里位置就在%LOCALAPPDATA%\Packages\...\LocalState下。这个文件很特殊你在 Linux 里删了文件、卸载了软件包空间并不会自动还给Windows。因为 ext4 文件系统删除数据后虚拟磁盘内部腾出了空间但 vhdx 文件本身不会主动收缩除非你显式压缩。这就是很多人明明清理了 Linux 却发现C盘丝毫没变的原因。1.3 87.81GB 这个数字具体是怎么分布的回到我这次的情况。我让 Codex 跑完统计后结果大概是这样的WSL2 的虚拟磁盘约 38GBnpm 缓存约 13GBpip 缓存约 8GBTemp 目录约 9GB浏览器缓存约 6GB剩下的零头分散在显卡着色器缓存、更新备份等地方。加起来差不多就是 87.81GB。这个报告其实解决了我最大的疑问——为什么我之前用各种清理工具“扫”不出东西。因为大部分清理工具只会盯系统临时文件和安全软件定义的“垃圾”它们根本不理解 npm 缓存、WSL 虚拟磁盘这种东西的存在。它们没做错只是规则覆盖不到这里。1.4 为什么 Windows 自带的清理工具常常无能为力Windows 的磁盘清理cleanmgr和存储感知扫出来的大头通常只有“系统更新备份”“临时文件”“回收站”。但 87.81GB 的 AppData 里真正的大头是开发链路的缓存和虚拟磁盘这些在系统自带的清理规则里根本不会主动处理。系统自带工具的逻辑是“保守优先”不确定能删的就不删绝不冒风险。这对普通用户是好事但对我们这种C盘已经被开发环境占满的人来说光靠它是不够的。你需要的是一个“能看明白每个目录是什么、有问题还能继续追问”的工具这正是我这次用 Codex 的原因。2. 为什么我选择让 Codex 来排查而不是直接用 SpaceSniffer2.1 传统磁盘扫描工具的三种不足我以前也用过 SpaceSniffer、WinDirStat 这类可视化工具方格图一出来确实震撼但深入用就会发现三个痛点能看大小不能解释用途。它给你一个超大目录的名字但不会告诉你“这是 npm 的缓存删了会自动重建”“这是 WSL 的磁盘删了系统就废了”。你得自己去搜挨个目录查非常费劲。交互是一次性的。扫描完、看完图对话就结束了。如果你想看某个子目录再往下钻、或者对比两个目录的差异又要重新扫一遍。遇到权限拒绝和隐藏目录给出的上下文很少。扫到一半报错你甚至不知道是卡住了还是正常。不是说这些工具不行它们依然有快速建立全貌的价值。但如果目标是“不仅查出谁大还想知道能不能删、为什么能这么删”传统工具就给不了答案了。2.2 Codex 在这个场景里的定位Codex 是一款可以跑在终端里的 AI 编程助手但我不把它当“写代码工具”用而是当“能执行命令的排查助手”。它能读取本地文件、执行 PowerShell 命令、看命令输出再基于这些结果继续推理。关键是它可以对话式地持续追踪一个问题不需要我手动把上一轮的结果复制粘贴给下一轮。在这次磁盘排查中Codex 实际上帮我做了三件事第一根据我“统计某个目录下各子目录大小”的需求生成并执行正确的 PowerShell 脚本第二把脚本输出整理成排序表筛出 TOP 级别的占用目录第三针对每个可疑目录解释它的用途、判断删除风险给出“能删/谨慎删/别删”的建议。这件事用传统方案不是做不到而是要把“写脚本、跑脚本、查资料、汇总判断”四步都自己做。Codex 的价值不是取代前三步而是把每一步之间的衔接成本大幅压下来。2.3 用 Codex 排查前的准备和边界设定我这次的操作环境是Windows 11 系统装有 Node.js LTS 版本。如果之前没装过 Codex一条命令就能装好然后在终端里完成登录和权限配置就能开始。我建议第一次使用就给它定好“工作边界”我的原话大概是当前目标排查C盘空间占用。请你只做只读分析和命令执行不要修改文件如果要删除或移动任何文件先告诉我等我确认后再执行。这句话非常关键。AI 助手不是不能执行危险命令但你必须把它限定在“可审计”的范围内。排查阶段它只负责读取和统计不负责处置处置阶段每一步都先出方案、等我确认。这样就算中间出了什么意外我也知道回滚的口子在哪。2.4 为什么“对话式排查”比“一把梭翻记录”更合适磁盘排查和写业务代码不一样它不是一次性能定义完需求的工作。通常过程是这样的看到第一层结果才知道第二层该查哪里看到第二层结果才知道哪些目录值得深挖。这本质上是一个迭代式的决策链。手工做的话最耗时的环节就是反复写 PowerShell 统计脚本。命令不难但每个目录层级都要调整路径、注意排除符号链接、处理权限错误来回折腾半小时很正常。而 Codex 能记住上下文它上一轮已经知道了 C 盘顶层有哪些目录、每个目录多大我只需要说“再往 AppData\Local 下面钻一层”它就能基于已有信息继续跑不需要我重新描述一遍背景。3. 完整排查实录从 C 盘全貌到揪出 87.81GB3.1 第一步让 Codex 输出 C 盘顶层目录占用排行排查开始时我并没有直接指定 AppData。我先让它统计当前用户目录下一级各文件夹的大小这样能对全局有个感知。Codex 生成的 PowerShell 脚本大致长这样$path C:\Users\MyName Get-ChildItem -Force $path -Directory | ForEach-Object { $size (Get-ChildItem $_.FullName -Recurse -Force -File -ErrorAction SilentlyContinue | Measure-Object Length -Sum).Sum [PSCustomObject]{ Path $_.FullName SizeGB [math]::Round($size / 1GB, 2) } } | Sort-Object SizeGB -Descending | Format-Table -AutoSize这条命令的本质是遍历指定目录下的每个子文件夹递归统计里面所有文件的大小总和。跑完后结果很清晰AppData 以 87.81GB 遥遥领先排在第二的是用户目录下的另一个数据文件夹只有几个 GB。也就是从这一刻起主战场被锁定在了 AppData。这里有个细节值得说这个统计脚本对大目录会跑得比较慢尤其是 AppData 这种十几万个文件的目录。我当时的做法是先跑完这一层拿到“嫌疑人名单”而不是一上来就做全盘扫描否则光是统计就要浪费大把时间。3.2 第二步顺着 AppData 逐级下钻找出“罪魁祸首”锁定 AppData 后我让 Codex 先分别统计Local、Roaming、LocalLow三个子目录的大小。结果很典型Local占了约 66GBRoaming占了约 20GBLocalLow只有零星几个 GB。这意味着大头都在本机专属缓存区域。继续下钻Local逐级统计后TOP 列表大概长这样目录占用Packages 下的 WSL2 虚拟磁盘约 38GBnpm-cache约 13GBTemp约 9GBpip 缓存约 8GB浏览器用户数据缓存部分约 6GB显卡着色器缓存约 4GB到这一步“87.81GB 是怎么构成的”已经非常清晰了。接下来的问题就是这些目录分别是什么、能不能删、删除后有什么后果。这一步才是 Codex 区别于普通扫描工具的核心价值所在。3.3 第三步追问 Codex“这是什么、能删吗”我的常用追问句式是每个目录帮我解释一下用途。按你的判断哪些是可安全清理的哪些需要谨慎哪些绝对不能动请给出依据。Codex 会结合 Windows 目录约定和命令输出结果逐项给结论。我印象比较深的几个判断npm-cache存的是 npm 下载过的依赖压缩包作用是加速后续安装。删除不会影响已安装的依赖只是下次安装依赖时需要重新下载速度会略慢。pip cache同理Python 包管理器下载的 wheel 包缓存删了安全。Temp目录里大部分是软件安装和解压过程留下的临时文件清理时最好先退出正在运行的程序否则可能提示文件被占用。WSL2 的 ext4.vhdx 是 Linux 文件系统的载体绝对不能直接删需要在 WSL 关闭后做压缩操作。Roaming下大部分是软件配置和登录态属于“不能乱动”的类型我只做统计不主动清理。这些判断如果你自己去查也能查到但每个目录都要去搜一圈时间成本太高。Codex 最大的帮助是把“判断链路”直接摆在面前我只需要最后决定“执行还是不执行”。3.4 过程中踩过的几个坑排查过程不是一帆风顺的有些问题现在想来很有代表性第一个坑是符号链接导致的重复统计。用户目录下存在不少目录联接junction比如某些开发工具会把数据目录软链到其他地方。如果没有跳过符号链接脚本可能顺着链接跑到别的盘去统计或者把同一个文件算两遍出来的数字就很离谱。后来我让 Codex 在统计脚本里加入对ReparsePoint属性的过滤结果才正常。第二个坑是“拒绝访问”报错。AppData 下也有少数系统受保护的文件统计过程中会抛错。如果不做错误静默处理脚本跑到一半就中断了后面全部白跑。所以脚本里的-ErrorAction SilentlyContinue不是偷懒是必要防御。第三个坑是深目录扫描耗时长。我的第一次全量统计跑了接近十分钟而且 PowerShell 单线程递归大目录确实会让人怀疑“是不是卡住了”。后来我调整为“先统计一层子目录再针对可疑目录单独下钻”效率高很多。这个思维同样适用于你手动排查的场景。4. 锁定目标后的删与不删我给出的完整处置清单4.1 先把目录分成三档可删、谨慎删、别删排查完之后最重要的就是处置。我按照 Codex 给出的解读把目录分成了三档分类代表目录处理方式放心删Temp 临时文件、npm/pnpm/pip 缓存、显卡着色器缓存、缩略图缓存删除后可自动重建无副作用谨慎删浏览器缓存、编辑器索引缓存、软件更新包残留删除后软件会重建缓存但可能丢失登录态或需重新索引别删Roaming 下的软件配置、WSL2 的 vhdx 实体、正在使用中的软件数据误删后轻则重新配置重则软件崩溃、子系统损坏这个分类不是拍脑袋定的核心逻辑就是我前面说的“生产者原则”凡是系统或软件能自动重建的都是“放心删”凡是重建成本高、或者本来就是唯一副本的就归入“别删”。4.2 WSL2 虚拟磁盘这种“大头”的标准处理方式WSL2 的 ext4.vhdx 是我这次最大的单个占用源也是很多人最容易误操作的目录。如果你直接把这个文件删了你的整个 Linux 子系统相当于被格式化所有数据、配置、安装过的软件全部没了。所以正确做法不是“删”而是“压缩”。标准流程是这样的# 第一步关闭所有 WSL 会话确保虚拟磁盘没有被占用 wsl --shutdown然后以管理员身份打开 PowerShell找到你的 vhdx 文件路径通常在%LOCALAPPDATA%\Packages\...\LocalState\ext4.vhdx执行压缩Optimize-VHD -Path $env:LOCALAPPDATA\Packages\...\LocalState\ext4.vhdx -Mode Full如果你的系统没有 Hyper-V 模块也可以改用 diskpartdiskpart select vdisk fileC:\Users\MyName\AppData\Local\Packages\...\LocalState\ext4.vhdx attach vdisk readonly compact vdisk detach vdisk exit压缩完成后重新打开 WSL确认里面的文件还在、命令能正常执行。这个操作的本质是把 vhdx 内部已经腾出的空闲空间“归还”给 Windows让文件体积缩回去。理论上可回收的大小取决于你在 Linux 里删了多少东西。4.3 逐项清理的可复现命令处理完 WSL2 之后剩下的目录就按部就班来。我建议的顺序是先清 Temp再清包管理器缓存因为它们都能自动重建风险最低。参考命令如下# 清空 Temp 临时目录最好先退出正在运行的程序 Remove-Item $env:LOCALAPPDATA\Temp\* -Recurse -Force -ErrorAction SilentlyContinue # 清空 npm 缓存 npm cache clean --force # 清空 pip 缓存仅当已安装 Python pip cache purge # 如果使用 pnpm pnpm store prune清完后记得重新统计一次 AppData 的大小确认释放了多少。当时我从 87.81GB 一路降到了大约 27GBC盘可用空间从不到 300MB 变成了 61GB 多。看到这个数字我才真正体会到“不是C盘不够大而是缓存管不住”这句话的分量。4.4 清理后必须做的验证步骤很多教程教完删除命令就结束了但我必须多说一句清理完成后至少要正常使用半天再下结论。我当时的验证清单是逐个启动常用软件确认浏览器能正常打开、编辑器配置还在、WSL 里的项目能跑起来、开发依赖能正常安装。没有报错才算清理成功。别刚删完看C盘变绿就觉得万事大吉有些软件重建缓存后第一次启动会特别慢或者某些登录态需要重新验证这些都要心里有数。5. 阻止 85GB 再次出现日常维护该怎么做5.1 给开发工具的缓存设置上限和迁移路径这次清理完我做的第一件事不是放松而是给那些“缓存大户”上枷锁。缓存不会因为删过一次就自动变乖它只会以同样的速度再次膨胀。常用的手段有三种第一种是给缓存指定非C盘路径。比如 npm 可以把缓存目录迁到 D 盘npm config set cache D:\dev-cache\npmpip 可以通过设置环境变量改变缓存位置# 设置用户环境变量 PIP_CACHE_DIRD:\dev-cache\pippnpm 则通过配置 store-dir 来实现pnpm config set store-dir D:\dev-cache\pnpm第二种是定期清理比如给自己设一个规则每月 1 号检查一次 Temp 和各类缓存超过 5GB 就清一次。不用动脑靠习惯保证。第三种是最彻底的把那些“不可避免会缓存”的目录整体迁到其他盘。这个我会在下面单独说。5.2 月度磁盘体检清单我把这次排查的经验整理成了一张简单的体检清单每个月照着做一次基本能避免C盘再次悄无声息地爆红检查项位置达标线临时文件%LOCALAPPDATA%\Temp超过 5GB 就清npm/pnpm/pip 缓存%LOCALAPPDATA%\npm-cache等超过 8GB 就清WSL 虚拟磁盘%LOCALAPPDATA%\Packages\...\LocalState超过 30GB 就压缩浏览器缓存浏览器设置内自带的清理超过 3GB 就清更新备份和还原点磁盘清理工具每月看一次即可每次体检不需要像第一次排查那样大动干戈重点就两个看趋势而不是看绝对值。哪个目录比上个月涨了 5GB 以上就说明它近期有高频写入要针对性处理。5.3 AppData 能不能直接整体挪到 D 盘我经常看到有人问“能不能把 AppData 整个挪到D盘”。答案是不要整体挪但可以有选择地挪。Windows 和很多软件对路径有硬编码你把整个 AppData 搬走可能导致大量软件找不到文件、系统组件失灵。正确做法是只迁移那些“重缓存”目录然后用目录联接junction让原路径仍然指向新位置。以 npm 缓存为例# 1. 把缓存目录从原位置复制到 D 盘 robocopy %LOCALAPPDATA%\npm-cache D:\dev-cache\npm /E /MOVE # 2. 在原来的位置建立目录联接 mklink /J %LOCALAPPDATA%\npm-cache D:\dev-cache\npm这样既把空间腾出来给了其他盘又保留了所有软件按原路径访问的能力。注意事项也很简单迁移前退出相关软件迁移后验证软件能正常读写别在迁移中途断电。5.4 用 Codex 做持续巡检经历了这次排查我意识到 Codex 这类工具还可以更进一步把月度体检也交给它。你可以让它写一个定期运行的磁盘统计脚本每次跑完输出一份“占用报告”按涨跌排名列出最近变化最大的目录。比如我后面就让 Codex 生成过一个简化的巡检脚本内容就是统计几个重点目录的大小、对比上次记录、输出差异。这个脚本我每个月手动跑一次大概十几秒就能看到结果一旦发现某目录快速增长就能提前处理而不是等到系统分区彻底变红才动手。最后再分享一点个人体会这次排查给我的最大收获不是“删掉了多少GB”而是建立了一个可复用的判断框架先搞清楚每个目录是谁创建的、删除后能不能自动重建再决定动不动手。AppData 里本来就分两种东西——能重建的缓存和不能重建的配置。用 Codex 来做排查核心价值就是把“瞎猜”变成“可审计的判断”让每一步清理都有据可依。如果你现在也正对着爆红的C盘发愁别急着装各种清理工具一键狂删。花二十分钟把一个目录一个目录的大小统计出来用 AI 助手帮你解释每个目录的用途。你会发现真正能安全释放的空间往往比想象中大得多而真正不能动的东西也比想象中好辨认得多。
