
好这个问题我太有共鸣了。C盘爆红几乎是每个用电脑的人躲不过去的一道坎尤其是开发机装点工具、跑几个项目、在线更新几个软件系统盘那张红色的容量条就慢慢爬满了。很多人第一反应是拿起磁盘清理工具一阵猛戳或者凭感觉删掉几个看着不顺眼的文件夹结果要么没删多少空间要么干脆把运行环境弄崩了。这次我换了个思路直接让Codex这个AI编程代理帮我在终端里跑分析命令、排查磁盘占用几轮对话下来锁定了用户目录下AppData文件夹累计占了87.81GB。这篇文章就把完整排查过程和清理方案整理出来给同样被C盘空间逼疯的朋友一个可以照着抄的作业。1. 先搞清楚C盘到底被什么吃掉了1.1 为什么不能上来就乱删我见过太多人清理C盘的姿势有问题。最常见的操作就是打开C盘看到哪个文件夹大就点进去删东西删完发现系统卡了、软件打不开了、开发环境起不来了最后只能重装系统。问题出在C盘根目录下很多看起来没用的文件夹其实都有明确的职责。我们可以把C盘想象成一个房子的承重墙。墙里面埋着水管电线你看着墙皮不顺眼用锤子凿开看看运气好只是蹭掉一层漆运气不好直接砸到承重结构整栋楼都跟着倒霉。系统的Windows文件夹、用户目录下的AppData、程序安装目录都属于这种里面有门道的地方。不是不能碰而是得先看清里面装的是什么再动手。1.2 AppData 到底是什么为什么它能长到80多GB先普及一个基础概念。在Windows系统里当前用户的个人数据默认放在C:\Users\用户名\AppData这个隐藏目录下面它被设计成三个子目录目录职责常见内容Local本机专属数据不跟着用户账户漫游缓存、临时文件、下载文件、软件私有的数据文件LocalLow给低完整度进程访问的数据浏览器保护模式缓存、旧版网页控件数据Roaming跟随用户配置文件漫游的数据软件配置、账号配置、对话记录、工作区设置很多软件默认不问你就把缓存、日志、临时文件、崩溃转储全塞进AppData\Local对应的子目录里。一个浏览器跑几个月光缓存就能攒出十几个GB开发工具链更是重灾区npm cache、pip cache、SDK临时文件哪个攒起来都不含糊。所以AppData长到87.81GB真不稀奇它就是一个大型垃圾桶和杂物间区别只在于里面的东西哪些能扔、哪些不能扔。1.3 87.81GB 是怎么被发现的这次没有走老路我直接打开终端让 Codex 帮我做全盘扫描。我的原话很简单看一下C盘各个顶级目录的大小把占用最大的列出来。Codex 会组合Get-ChildItem和Measure-Object去递归统计每个目录的体积。我当时给的任务是找出占用最大的文件夹它返回的第一条结论就是C:\Users\当前用户\AppData占了87.81GB。这里有个容易忽略的细节普通人的直觉是先看Program Files或者Windows文件夹但实际在大多数用户机器上AppData的体积会轻松超过程序安装目录。因为软件本体也就几十MB到几个GB但运行过程中产生的缓存、快照、临时数据往往是本体体积的几倍甚至几十倍。2. 用 Codex 做磁盘体检的整体思路2.1 为什么这次选 Codex 而不是传统磁盘分析工具平时我电脑上备着几款磁盘分析工具扫得快是它们的优势但它们只能告诉你哪里占用了多少给不出这些东西能不能删、怎么删最安全的决策建议。这次我抱着试试看的心态用 Codex一是因为它能直接执行终端命令二是它可以把复杂的统计脚本拆成人类能理解的步骤每一步还能解释为什么这样做。用 Codex 排查磁盘本质上不是在问它要不要删某个文件而是让它作为一个懂命令行、懂Windows文件系统约定的助手替我把分析过程跑完。我只需要看结论再让它针对具体目录做二次、三次下钻不需要自己拼写一堆PowerShell参数。2.2 第一轮定位占用最大的顶级目录第一轮任务我给得很宽泛。下面是当时用的统计脚本原理就是遍历C盘根目录下的所有一级文件夹把每个文件夹的体积递归加起来再按大小倒序排列Get-ChildItem C:\ -Force -Directory -ErrorAction SilentlyContinue | ForEach-Object { $sum (Get-ChildItem $_.FullName -Recurse -Force -File -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum).Sum [PSCustomObject]{ Name $_.Name SizeGB [math]::Round($sum / 1GB, 2) } } | Sort-Object SizeGB -DescendingCodex 帮我把这个脚本跑完整了输出结果里AppData排第一87.81GB。排在后面的分别是Windows、Program Files、ProgramData和页面文件相关数据。这轮结果对我最大的触动是我原本以为开发工具装了好几个IDE占用最大的肯定是工具链目录实际上工具链加起来才不到30GBAppData 才是真正的庞然大物。2.3 第二轮把 AppData 里的大户揪出来知道大户是 AppData 之后我开始下钻。先看 Local 目录因为它通常是最能藏东西的地方Get-ChildItem $env:LOCALAPPDATA -Force -Directory -ErrorAction SilentlyContinue | ForEach-Object { $sum (Get-ChildItem $_.FullName -Recurse -Force -File -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum).Sum [PSCustomObject]{ Folder $_.Name SizeGB [math]::Round($sum / 1GB, 2) } } | Sort-Object SizeGB -Descending | Select-Object -First 20这次输出就有意思了。排在前面的几乎清一色是缓存和临时数据目录临时文件目录、浏览器缓存目录、崩溃转储目录、某个包管理器的全局缓存、某个开发工具的历史记录。单个看来都不算夸张但十几个叠在一起量变引起质变累加到了几十个GB。Codex 还帮我做了一件加分的事它对每个大目录给出了一句内容说明比如哪部分是缓存可以清理、哪部分是配置数据不建议动。这一步比单纯给出数字有用得多省了我逐个目录上网确认的时间。3. AppData 内可清理项完整拆解3.1 哪些能安全删除在AppData里真正占空间且属于无价值数据的基本集中在下面这几类第一是临时文件目录。%LOCALAPPDATA%\Temp里面大部分是软件运行过程中产生的中间文件软件退出后就没用了。第二是崩溃转储和故障日志目录比如%LOCALAPPDATA%\CrashDumps保存的是程序崩溃时的内存快照对普通用户来说几乎没有保留价值删掉也绝对不会影响后续问题排查因为新崩溃会生成新快照。第三是各类缓存目录包括浏览器缓存、系统缩略图缓存、包管理器缓存。说到包管理器缓存开发人群要重点关注。node 生态的npm或pnpm会把下载过的包压缩文件缓存在%LOCALAPPDATA%\npm-cache或%LOCALAPPDATA%\pnpm-cachePython 生态的pip也一样缓存在%LOCALAPPDATA%\pip\Cache。这些缓存如果长期不清理动辄就是几十GB。我把这次清理前重点审视的目录整理成了一张表操作前对着它过一遍比凭感觉删安全得多目录路径%LOCALAPPDATA% 指 C:\Users\用户名\AppData\Local说明可否清理注意点%LOCALAPPDATA%\Temp系统与软件临时文件可清理先退出所有运行中的软件%LOCALAPPDATA%\CrashDumps崩溃转储文件可清理不影响未来崩溃记录%LOCALAPPDATA%\Microsoft\Windows\Explorer缩略图缓存可清理自动重建%LOCALAPPDATA%\Microsoft\Windows\INetCache旧版IE/Edge缓存可清理新浏览器不受影响%LOCALAPPDATA%\npm-cachenpm全局缓存可清理下次安装会重新下载%LOCALAPPDATA%\pip\Cachepip下载缓存可清理下次安装会重新下载%LOCALAPPDATA%\D3DSCache图形着色器缓存可清理部分游戏首次启动变慢%APPDATA%\某个软件软件配置与账号数据不建议清理删了会丢配置%LOCALAPPDATA%\Programs部分软件的安装位置不要删删了软件直接失效注意清理 Temp 前最好把正在运行的浏览器、设计软件、游戏都退出。否则正在被占用的文件会提示删除失败还会留下一些半删状态的残留。3.2 哪些绝对不能碰AppData里除了垃圾数据还有大量真正的家底。Roaming目录下通常保存着软件的配置文件、账号登录信息、数据库连接配置。我把某个开发工具的配置文件误删过一次它启动后直接回到初始状态所有个性化设置、插件启停状态、窗口布局全部丢失我花了两个小时才恢复大部队。所以这不是能不能删的问题而是删了之后你要付出多少时间成本的问题。另外要特别注意%LOCALAPPDATA%\Programs和%LOCALAPPDATA%\Microsoft\Windows\Apps这两个地方。前者是一些安装时选择仅当前用户的软件的实际安装位置比如用户级安装的开发工具、命令行工具后者是Windows商店应用的部署目录。删这里面的东西后果等同于直接在程序列表里卸载软件但卸载流程不会走容易留下注册表和依赖清理不干净的问题。判断标准其实很简单文件被创建后不会被反复写入或者内容与你的账户配置强相关的基本都不能碰那些名字里带 Cache、Temp、Log、Crash、Backup 且体积还很大的大概率可以安全清理。3.3 一个可以直接套用的清理参考脚本实际上我没让 Codex 直接执行清理而是让它把清理逻辑写成脚本给我审阅。这算是我给自己设的一道安全闸毕竟这种批量删除操作一旦路径写错波及面会很大。脚本思路如下# 清理前一定先退出浏览器、IDE、聊天软件等正在运行的应用 $targets ( $env:LOCALAPPDATA\Temp\*, $env:LOCALAPPDATA\CrashDumps\*, $env:LOCALAPPDATA\Microsoft\Windows\Explorer\thumbcache_*.db, $env:LOCALAPPDATA\Microsoft\Windows\INetCache\*, $env:LOCALAPPDATA\npm-cache\*, $env:LOCALAPPDATA\pnpm-cache\*, $env:LOCALAPPDATA\pip\Cache\*, $env:LOCALAPPDATA\D3DSCache\* ) foreach ($target in $targets) { Remove-Item $target -Recurse -Force -ErrorAction SilentlyContinue }注意这里有一层保护逻辑所有路径都用了\*通配符只删目录里的东西保留目录本身。这样做的好处是即使某个软件的缓存目录正在被写入删除失败最多报个错不会把整个目录结构破坏到让软件无法启动的程度。配上ErrorAction SilentlyContinue也不会遇到一个权限错误就中断整轮清理。在我这台机器上这一轮清掉了大约31GB。剩下的空间大头是某些软件的缓存数据比如设计类软件的资产缓存、浏览器的站点数据这些关联到用户实际使用体验我没继续往深挖而是选择从源头控制让它们别再膨胀。4. 实操中的常见问题与排查技巧4.1 删文件时提示正在使用怎么办这是清理 AppData 最常遇到的拦路虎。很多缓存文件被软件进程锁定普通模式下怎么删都删不掉。我踩过几次坑后总结了一套顺序先正常退出软件等几秒让进程完全结束如果还是删不掉打开任务管理器的性能选项卡看底部的打开资源监视器在 CPU 选项卡里输入文件路径关键字找到占用进程右键结束进程后再删除。这种办法比硬重启系统效率高得多也精准得多。如果显示文件系统权限错误比如你需要来自 XX 的权限才能修改此文件夹先别急着用 Everything 或者强制删除工具去抢权限。绝大多数情况下这不是权限不够而是文件正被某个受保护进程持有或者该目录带有特殊的继承属性。强制修改 ACL 可能会把系统目录的权限模型搞乱得不偿失。4.2 递归统计脚本跑得非常慢第一次用 PowerShell 全盘统计时光是扫C盘就等了将近二十分钟。因为Get-ChildItem -Recurse要逐文件遍历命中很多系统保护目录还会反复触发权限错误。后来我调整了策略先用快速扫描工具比如固态硬盘上的磁盘占用分析工具定位大文件夹秒级出结果再用 Codex 编写的精细脚本只针对有希望清理的目录做精确统计。这样两轮下来速度和准确性都兼顾了。另外给 Codex 下指令时建议加一句跳过访问受限的目录。普通用户模式下访问System Volume Information这类受保护目录本来就会失败报错信息刷屏只会干扰判断加上ErrorAction SilentlyContinue之后输出会干净很多。4.3 Codex 生成的删除命令有风险怎么办AI生成的脚本不能无脑执行这个习惯一定要养成。我的做法是先要求 Codex 解释每一条命令的作用如果它写的是Remove-Item配合-Recurse -Force我会特别警惕目标路径是否精确。还要让它先输出将要删除的文件数量和总大小的统计结果确认无误后再执行。更稳妥的做法是让 Codex 写脚本时统一加上-WhatIf参数。这个参数是 PowerShell 里天然的演练模式执行时只会打印出将要执行的操作不会真删。等确认无误去掉-WhatIf再跑一遍即可。这一步看似多花了一点时间但能避免把某个缓存目录的父级路径写错后带来的连锁反应。5. 从源头减少 C 盘膨胀的几个习惯5.1 给系统安装盘留出呼吸空间清理只是一时爽如果不改变软件的存储习惯C盘过两个月还是会红。我后面做的几个调整才是治本的关键。第一是把系统的休眠文件控制策略重新梳理了一遍。Windows 默认会为休眠功能保留一个与内存大小相当的文件在C盘根目录。如果平时只是合盖睡眠、不依赖休眠可以在管理员终端里执行powercfg /h off关闭休眠一次释放几个甚至十几个GB。如果还需要快速启动功能可以改用powercfg /h /type reduced把休眠文件压缩到最小体积。这一步在清理完 AppData 之后做效果非常直观。5.2 调整包管理器和浏览器的缓存位置针对开发工具我做的第二件事是重定向包管理器缓存到其他分区。npm 和 pip 都支持通过配置文件或环境变量指定缓存目录。我在D盘建了一个隐藏目录把缓存路径指过去。这样即使C盘空间再紧张也不会让下载缓存挤占系统盘。代价是第一次安装依赖会重新下载压缩包但现在的网络速度完全可以接受换来的是系统盘的长期稳定。浏览器的缓存也一样。很多现代化浏览器支持在设置里修改缓存路径把缓存目录移到机械盘或者容量充裕的分区能在日常使用中持续减少C盘写入量。这件事做完短期内看不出变化但跑三个月后再扫一次C盘差距就出来了。5.3 周期性给 AppData 做体检最后一个习惯是给自己定了一个节奏每个月底用 Codex 跑一次 AppData 目录扫描看看哪个缓存目录本月增长速度最猛再决定要不要清理、要不要重定向。我之前就是吃了从不体检、事到临头才处理的亏让 AppData 一路长到87.81GB都不自知。有了这个例行检查现在每次看到的占用数字基本稳定在合理范围再也没出现过C盘爆红才手忙脚乱的情况。如果你和我一样被这个80多GB的教训吓到过不妨现在打开终端让 Codex 帮你列一下 AppData 的体积分布再对照前面那张可清理清单花一个晚上把系统盘彻底梳理一遍。比起忍受长期卡顿和随时可能崩溃的磁盘空间花在排查上的这几个小时绝对值得。我自己的体会是清理C盘不是越勤越好而是要建立一套定位-判断-清理-防复发的闭环。借助 Codex 这样的工具可以把最耗时的定位和统计环节压缩到几分钟把精力留给更关键的问题——判断哪些数据有价值、哪些是彻头彻尾的数字垃圾。这个思路理顺了C盘爆红就不是什么玄学问题而是一个可以定期维护的常规工程。