C盘又红了。不是那种还剩几个G的轻微黄色警报是真真切切的爆红。打开资源管理器系统盘剩余空间显示是0字节Windows 更新直接罢工浏览器下载文件失败连输入法都开始有延迟。这时候大部分人第一反应是清桌面、删安装包、卸载几个不用的软件但通常折腾半小时磁盘空间还是没多大变化。真正的大头往往藏在C:\Users\你的用户名\AppData这个目录里。我这次遇到的情况就是典型中的典型整个C盘一共就两百来GAppData 一个目录占了87.81GB接近一半的容量都被它吞了。更坑的是AppData 下面塞满了缓存、日志、临时文件、数据包看起来全都不认识根本不敢乱动。这次我没有靠肉眼一层层翻而是直接用 Codex CLI 帮我做了递归扫描把87.81GB逐项拆开最后安全腾出40多G的空间。这篇记录里我会完整复盘整个排查和清理过程包括每一步的脚本、哪些能删哪些千万别碰、以及我踩过的几个坑。如果你正对着爆红的C盘发愁这篇文章应该能帮你在半小时内定位到真正的空间杀手。1. 动手之前先想清楚这87.81GB到底藏在哪1.1 为什么不能上来就乱删很多人见到C盘爆红第一反应是“把 AppData 里看着没用的东西删掉”。但 AppData 不是普通的垃圾文件夹它是 Windows 给当前用户划出来的私有数据区里面装着大量程序的配置、缓存、数据库、会话状态甚至还有你的聊天记录和登录凭证。直接整目录删轻则软件回到初始状态重则数据丢失、系统组件损坏。我的排查原则非常简单先量化再分析最后才动手删。量化是告诉你“问题有多大”分析是告诉你“问题具体在哪”只有到了第三个阶段才轮到真正执行清理操作。这套流程不管是用Codex还是用传统脚本逻辑都一样——先搞清楚敌人有多少、在哪个位置再决定派多大火力。1.2 AppData 的三个子目录各管什么AppData 下面有三个目录职责完全不同。Local 是“本地数据”存的是只属于这台机器的缓存和程序数据比如浏览器缓存、下载目录、崩溃转储还有各种应用的 Cache 目录。LocalLow 比较冷门主要给低权限应用和浏览器插件用体积一般不大。Roaming 则是“可漫游数据”Windows 默认认为这些数据应该跟随用户配置文件同步到域环境中所以很多软件的设置、聊天记录、历史记录都存在这里。这个分工决定了清理策略的优先级Local 是缓存重灾区Roaming 里则有不少“删了会出事”的数据文件。87.81GB 的占用里大部分都集中在 Local尤其是浏览器缓存和装机工具的虚拟磁盘文件。1.3 排查前先定好三个纪律动手之前我先给自己定了三条纪律。第一只分析不删除扫描脚本可以反复跑但删除动作必须人来确认。第二先统计后甄别先让脚本列出体积最大的目录再逐项判断它是什么、能不能删。第三缓存优先动、数据配置最后动凡是名字里带 Cache、Temp、Crash、Log 的优先级最高凡是看起来像数据库、配置、存档的一律先放着。这三个纪律看着简单实际操作中能救命。因为一旦脚本给了你一份Top目录名单很容易产生“看起来都像垃圾”的错觉然后就冲动执行了一键清理。真删坏了再回头就晚了。2. 用 Codex 自动扫描 AppData脚本思路与实操记录2.1 为什么这次选了 Codex这次排查我用的工具是 Codex 的终端版CLI。它的价值在于你不需要记住一堆 PowerShell 的管道命令怎么写只需要把目标说清楚它会直接生成遍历脚本还能帮你解释输出结果甚至根据结果建议下一步怎么定位。这个场景特别适合“半探索半操作”的任务——我们根本不知道大头在哪需要反复尝试不同的统计维度如果用传统方式每改一次脚本都要自己动手效率低很多。当然Codex 不是魔法它不会“自己”去删东西所有删除动作都需要我确认它给出的命令后手动执行。这一点后面细说。2.2 环境准备前置条件很少一台 Windows 10/11 的机器一个装了 npm 的终端环境然后全局安装 Codex CLI。安装命令很简单终端里执行npm install -g openai/codex或者直接用安装脚本都行。装完之后建议先确认一下版本号打印出版本信息就说明环境没问题。注意如果终端提示权限不足需要以管理员身份重新打开终端。不过后面扫描 AppData 时不建议全程用管理员权限因为那会让你误删很多正常数据。普通权限足够扫描用户目录了。2.3 第一轮粗扫三个一级目录我的要求很直接统计 AppData 下三个子目录的总大小。Codex 给了我一个很清爽的 PowerShell 脚本逻辑是遍历每个目录下的文件累加 Length 属性。跑完之后输出如下$paths ( $env:LOCALAPPDATA, $env:LOCALAPPDATA\..\LocalLow, $env:APPDATA ) foreach ($p in $paths) { $size (Get-ChildItem -Path $p -Recurse -Force -File -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum).Sum [PSCustomObject]{ Path $p SizeGB [math]::Round($size / 1GB, 2) } }输出结果让我确认了猜想Local 占了非常大的一块Roaming 只有它的零头LocalLow 几乎可以忽略。这说明主战场在 Local下一步要钻进去看里面谁的体积最大。2.4 第二轮进入 Local 目录输出 Top 20只统计三个一级目录还不够因为 Local 下面有几十个程序目录我还是不知道具体是哪家占的。于是让 Codex 写了一个“统计一级子目录体积并排序”的脚本。$target $env:LOCALAPPDATA $results Get-ChildItem -Path $target -Directory -Force -ErrorAction SilentlyContinue | ForEach-Object { $size (Get-ChildItem -Path $_.FullName -Recurse -Force -File -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum).Sum [PSCustomObject]{ Name $_.Name SizeGB [math]::Round($size / 1GB, 2) } } $results | Sort-Object SizeGB -Descending | Select-Object -First 20 | Format-Table -AutoSize这个脚本的作用相当于把所有候选者拉到台面上按体积排座次。输出结果里冒出好几个熟面孔一个浏览器系列的目录、一个容器运行时目录、一个前端包管理器缓存目录还有一个系统临时目录。看到名单的那一刻87.81GB 的谜底已经揭晓一大半了。2.5 怎么验证数据是准的脚本算出来的数字能不能信我做了两件事来验证。第一直接选中 AppData 文件夹看属性Windows 资源管理器显示的体积和脚本统计的87.81GB基本一致误差不超1%。第二用系统自带的存储感知再看一遍虽然它不会细分到目录级别但总量对得上。经验之谈PowerShell 统计大目录时速度很慢87GB可能要跑几分钟。如果嫌慢可以用“逐层剪枝法”——先只看第一层子目录大小再挑大的继续往下钻而不是一上来就递归全部。Codex 交互时也推荐了这个策略点开即用。3. 大文件拆解AppData 里的空间都去哪了拿到 Local 目录的 Top20 名单后接下来就需要逐项拆解。这里我必须强调目录名只能作为线索不能直接当结论有些应用名一看就懂有些系统目录则需要看里面的内容才能判断。3.1 缓存类占用浏览器和 Electron 应用Top名单里排在前面的通常是浏览器类的目录。浏览器会把网页的图片、脚本、字体、视频切片全部缓存到本地缓存目录通常叫 Cache、Code Cache、GPUCache、Service Worker\CacheStorage 这类名字。单一文件不大但数量极多积少成多跑到10GB以上很常见。更隐蔽的是 Electron 架构的桌面应用。很多聊天软件、编辑器、团队协作工具都是 Electron 套壳它们同样在 Local 下生成一堆 Cache、blob_storage、GPUCache、Code Cache。如果电脑上装了多个这类应用加起来的缓存量能惊掉下巴。我机器上光这类应用加一起就清理出将近15GB。3.2 开发环境的缓存npm、pnpm、pip 与构建缓存如果你平时写代码那么开发工具缓存绝对是空间大户。npm 的缓存目录会保存所有下载过的包压缩文件日积月累能到好几个G。pnpm 的 store 更夸张因为它是一个全局内容寻址存储所有项目共用的包都会留在里面不主动 prune 的话会持续膨胀。pip 的 cache 在 Windows 上同样不容小觑尤其是经常做机器学习的会下载大量预编译包。还有一类是构建缓存比如 gradle 的 modules-2、Unreal 的 ShaderCache、Unity 的 GI Cache它们在开发和游戏制作场景下能轻松吃到几十个G。这类缓存的特点是“删了没事下次构建或启动时会自动重建”只是重建过程会消耗一点时间。3.3 Docker 虚拟磁盘藏在 Local 里的巨型黑盒名单里另一个大头很可能是 Docker 相关的目录具体位置在Local\Docker\wsl或者Local\Docker下面的disk目录里。里面那个docker_data.vhdx文件就是容器数据的虚拟磁盘它可能占据30GB甚至60GB。这里有个很容易踩的坑Docker 默认会把虚拟磁盘文件放在 C 盘 AppData 下而且这个文件是“稀疏扩容”的——起初很小用多久胀多大但当你删除镜像、停止容器之后它并不自动缩回去。也就是说即使你删光了所有镜像那个 vhdx 还是那么大。这就是为什么很多人发现 Docker 相关占用永远清不掉。处理方式不是直接删文件而是压缩虚拟磁盘后面的清理章节会写具体步骤。3.4 聊天软件和同步盘的本地下发缓存再往下看名单里出现聊天工具和网盘类工具也很正常。这类软件有一个共性默认把接收的文件、聊天图片、视频临时副本放到 AppData 目录尤其是 Roaming 下的公司名目录里。你以为是“聊天记录”实际上大部分是媒体缓存。我这次在 Roaming 下就发现一个软件的本地消息数据库和图片缓存加在一起超过8GB而且它不支持单独更换目录只能进应用设置里清理。这里特别提醒一句聊天软件的“历史记录”和“本地缓存”是两回事前者是数据库后者是媒体文件副本清理前一定要先在应用内确认哪些能被安全释放。3.5 系统自己制造的临时文件和错误报告AppData 里还藏着相当一部分系统生成物。Local\Temp是用户临时目录很多程序解压临时文件、更新安装包都会写到这里旧文件不会被自动清理。Local\Microsoft\Windows\WER是 Windows 错误报告目录崩溃时生成的转储文件常常单个就几百MB。CrashDumps、GPUCache、FontCache这些目录同样属于“看起来没用、实际上确实没大用”的类型。这类系统缓存的特点是删除后不会产生严重后果最多是让某个程序启动时多加载一次字体或重新生成缓存。但问题是目录名字不够直观很多人不知道它们是什么于是反而把它们留了下来。3.6 常见占用类型速查表为了方便对照排查我把这次扫出来的几类常见占用地盘整理了张表按“可清理性”从高到低排列。占用类型典型路径Local/AppData 下体积参考可清理性浏览器缓存Chrome/Edge 的 Cache、GPUCache、Code Cache5-20GB高可放心清Electron 缓存各种应用的 Cache、blob_storage5-30GB高但要求应用兼容开发包缓存npm-cache、pnpm/store、pip/Cache3-15GB高清后要联网重建Docker 虚拟磁盘Docker/wsl/disk/*.vhdx10-60GB中需压缩不可硬删聊天媒体缓存Roaming 下各软件的本地文件2-15GB中应用内清理更稳系统临时文件Temp、WER、CrashDumps1-5GB高应用配置与数据Roaming 下的数据库、Settings不定低非必要不动这张表的最大价值不是“背下来”而是让你在扫描结果里看到某个目录时能第一时间判断它属于哪个类型从而决定下一步该快刀斩乱麻还是绕着走。4. 安全清理实操该删的、可删的、千万别动的4.1 先做一件最容易被忽略的事重启系统清理 AppData 之前我强烈建议先把系统完整重启一次。原因很简单大量缓存文件正被运行中的进程占用Windows 不会让你删掉正在使用的文件于是会出现“明明看到空间被释放了一半但磁盘可用空间没变”的诡异情况。重启之后后台程序重新加载很多临时文件不再被锁定删除成功率会高很多。这是我在多次清理经历中总结出的最前置、最省心的步骤比任何命令都管用。4.2 缓存类清理命令一览清理缓存时我偏好“用应用自带命令手工目录清理”结合。应用自带命令最大好处是安全而手工目录清理效率高。下面几条是我实际跑过并且推荐的做法# 前端包管理器缓存 npm cache clean --force pnpm store prune # Python 包缓存 pip cache purge # 浏览器缓存一般直接删目录内文件先退出浏览器 # 例如清理 Local\Google\Chrome\User Data\Default\Cache 下的文件 # 或直接用系统自带清理工具 # 打开“存储感知”勾选“缓存的图像/临时文件/缩略图”后立即清理另外系统自带的磁盘清理工具cleanmgr.exe也别浪费它可以清理 Windows 更新缓存、缩略图、临时文件。我一般会用管理员模式跑一次把“Windows 更新清理”选上经常能释放出几个G。别小看它虽然不在 AppData 里但它和 C 盘爆红问题是同一个战壕里的。4.3 Docker 虚拟磁盘压缩实操这是这次清理里最“硬核”的一步。前面说了直接删 vhdx 是拆家的行为正确做法是压缩。压缩前先备份或者停掉所有容器然后在管理员终端里依次执行wsl --shutdown diskpart等 diskpart 交互环境起来后select vdisk fileC:\Users\你的用户名\AppData\Local\Docker\wsl\disk\docker_data.vhdx attach vdisk readonly compact vdisk detach vdisk exit执行完 compact 之后再看文件大小通常会从四五十个G缩水到用量的实际体积。我这次硬生生从30多G压到12G。这一步操作风险比单纯删缓存高建议新手操作前先确认 Docker 里的容器数据有没有备份。注意Diskpart 的 compact 在部分 Windows 版本上会提示不兼容这时可以改用 PowerShell 的Optimize-VHD -Path xxx -Mode Full功能和逻辑等价但需要系统安装 Hyper-V 管理工具。两条路走通其中一条就行。4.4 应用迁移从根上防止复发清理完之后还有一个防复发的重要动作把能挪走的“大家伙”挪出 C 盘。有两类应用值得动手。第一类是支持自定义缓存路径的开发工具比如 Docker Desktop 的镜像存储目录就是可以改的npm 的 global prefix、pip 的 cache-dir 也都可以把缓存指到 D 盘。第二类是体积大但又不能删的软件比如游戏平台、虚拟机重装时选择其它盘即可。我给所有正在读这篇的人一个建议不用追求所有软件都装 D 盘但至少把缓存类目录和虚拟磁盘类文件驱逐出 C 盘。这样哪怕下次 AppData 又涨起来第一个拦路的也不再是你。4.5 清理后的复核重新开启“上帝视角”清理完不是关电脑就完事一定要回到脚本视角再统计一遍。我清理后让 Codex 重新跑了一次同样的扫描看到 AppData 从87.81GB降到40多GBTop20 里的缓存目录明显瘦身Docker 目录压缩成功才敢确认这一轮操作有效。这个“先扫描-清理-再扫描”的闭环是整篇文章最核心的方法论。删除动作是否生效、哪些目录拒绝释放、清理后有没有异常反弹全部反映在前后两次扫描的对比里。5. 高频问题与避坑实录5.1 脚本跑一半提示拒绝访问这是统计 AppData 时最常见的问题。原因很简单有些子目录属于其他用户或者被系统保护当前权限不够。处理方式是在脚本里加上-ErrorAction SilentlyContinue让它跳过无法读取的部分而不是整个崩溃。不过要注意静默跳过意味着某一块体积可能被低估。如果最后发现统计结果和资源管理器显示差异较大就单独去那几个报错的目录看一眼手动判断。5.2 统计速度慢得让人想放弃AppData 里文件数量动辄几十万个PowerShell 一条条才过去查属性速度自然快不了。我建议分两步走第一步先统计一级子目录快速确定谁是老大第二部再对老大的子目录继续拆分。不要一上来就全部分析。如果在意速度可以在 Codex 里让它改用Get-ChildItem -Depth 2限制递归深度或者用robocopy的列表模式来加速遍历。反正最终目的都是锁定那几个大块头不需要精确到每个字节。5.3 清完缓存之后某个软件打不开了这个坑出现在“你以为的缓存其实是数据”的场景里。有些软件会把关键配置放在看似缓存的位置比如 Local 根目录下的 Settings 文件夹、数据库子目录、session 文件。我在清理一个装机工具时就差点把它的会话数据库当成缓存删掉。经验教训任何带 Store、Database、Config、Session、Data 字样的目录在没有明确说明的情况下都先保留。只清理名字里带 Cache、Temp、Log、CrashDump、blob 的目录。把这条阈值写进你的决策逻辑里基本不会翻车。5.4 清理完可用空间纹丝不动有几个原因。第一是大量文件被占用删除失败但没提示第二是虚拟磁盘类文件就算删了内部数据文件大小也没变需要专用压缩第三是回收站还没清空看起来删了空间没回来。对应做法重启后再试对 vhdx 做压缩清理完清空回收站。如果以上都做了可用空间还是没变再检查是不是开了系统还原或文件历史记录这些功能会占用额外空间。5.5 问题速查表症状主要原因处理方式统计结果比属性少很多权限不足部分目录被跳过单独扫描报错路径确认内容删除失败提示占用程序仍在运行文件被锁重启系统后重试空间没释放缓存删的不是可能的部分做前后对比继续深挖软件打不开误删了配置/数据目录回收站还原或重装修复Docker 体积不变vhdx 需压缩用 diskpart/Optimize-VHD 压缩这张表基本覆盖了我能想到的常见坑。如果你遇到的情况不在里面大概率是某个特定软件的私有目录那就去软件设置里找自带的清理功能比任何通用策略都稳。6. 我踩过的坑和现在的习惯这次排查能顺利收官是因为前面已经踩过足够多的坑。我现在的习惯是每两周跑一次目录体积统计脚本把 AppData 的Top 10 输出存成文件浏览器缓存和临时目录随手清开发包缓存每个季度 purge 一次Docker 的 vhdx 会在每轮大清理后顺手压缩一次。这套节奏下来C盘基本能维持在安全工作水位。还要推荐一个心态不要指望一份列表全部看清C盘清理本来就是个“迭代式”的过程。第一轮删掉明显缓存第二轮消灭大文件虚拟盘第三轮处理各自的私有数据每一轮都比上一轮更精确。我用 Codex 扫了不到十分钟但它真正帮我省时间的地方不是“写脚本”这个动作而是让我不用去手翻那些陌生的目录平白无故研究半天。最后再分享一个很小的习惯清理Action前先看一眼回收站。你会发现很多看似“清不动”的空间其实只是自己从没清空过回收站。等这些全部清下来C盘的红条重新变蓝的那一刻你会觉得前面花的半小时特别值。