C盘爆红不用怕：用Codex精准清理AppData释放87GB空间-北京尧图网络

C盘又飘红了。这回不是那种还剩二三十GB的轻度飘红而是剩余可用空间只有3.2GB连浏览器下个压缩包都会弹磁盘空间不足提示的严重状态。我习惯性打开系统自带的磁盘清理扫了一圈能清理的量只有4.6GB删完撑了不到两天又红了。以前遇到这种情况我多半会开始一场碰运气式的删文件大赛但这次我决定换个思路。我用 Codex 写了个针对用户目录的扫描脚本把C:\Users\用户名\AppData从里到外算了一遍账最后得到的数字是这个目录占了 87.81GB几乎就是C盘飘红的全部原因。这个结果其实挺反直觉。很多人觉得C盘爆红肯定是系统更新缓存、休眠文件在作怪但对我这台开发机来说真正的元凶一直在用户目录里。AppData 是 Windows 用户平时很难注意到的目录属性窗口转半天都算不完里面文件成千上万名字大多是很长很怪的哈希字符串看着就头大。正是因为它又大又乱又难懂才会变成C盘空间的黑洞。这篇文章我完整记录一下怎么用 Codex 把它查清楚的以及清完之后哪些能删、哪些能迁、哪些碰都不要碰。1. 先别急着删文件C盘爆红时的三种作死姿势1.1 那些年我们一起翻过车的清理在得出 AppData 这个结论之前我身边已经有不少人用亲身经历证明过乱删一时爽的后果。我见过有人嫌系统更新备份占地方直接把相关目录整个删掉结果系统组件缺失后续补丁怎么都打不上最后只能重装。有人对公共数据目录下手删了某个软件的共享数据文件夹那个软件从此启动就报错重装都不顶用。更常见的是清理临时目录时把正在运行的应用文件当成垃圾处理删完才想起来刚才那个 IDE 的索引还写在里面。这些翻车案例有个共同点都是在没有完整目录占用数据的情况下凭这个文件夹看起来没用的感觉动手。我后来总结出一条经验——C盘清理的第一原则不是快而是先搞清楚每个目录有多少数据、属于哪个应用、删掉之后会有什么影响。数据量不明就开删本质上是在赌运气。1.2 为什么看着属性窗口越看越不知道该删什么没有明确数据之前大部分人判断哪里占地方靠的是资源管理器的属性对话框。这个操作在小文件夹上没问题但遇到 AppData 这种层级深、文件数量大的目录属性对话框经常要卡上半分钟甚至更久。我之前试过右键 AppData 点属性计算进度条走了将近十分钟才出来期间整个资源管理器都是假死状态。更重要的是就算属性窗口告诉你 AppData 有 87.81GB你也只知道这一个数字。它不会告诉你哪一层子目录消耗最大不会告诉你里面的缓存属于哪个软件更不会给出可清理和不可清理的边界。你看到的只是一个黑盒子然后会一边看着数字一边纠结到底要不要删删哪个这正是很多清理工具能帮你定位问题、却没法帮你解决问题的原因。1.3 核心思路先量化一遍再决定动谁所以这次我给自己定的路线很明确第一步把 C 盘的目录占用彻底量化第二步对照量化结果分析每一类的性质第三步在确认安全的前提下清理或迁移。整个流程不靠眼睛和鼠标拍脑袋而是借助 Codex 来生成扫描脚本和分析结论。量化这件事最直接的做法就是写一个目录扫描器遍历指定根目录下的所有子目录把每个目录里的文件大小加总最后按大小倒序输出一份清单。这听起来简单但细想会发现几个现实问题——目录数量多的时候递归遍历很容易超时或卡在权限错误上输出结果一堆哈希目录名根本不知道对应的是哪个软件。这些问题恰好是 Codex 擅长处理的。2. 硬盘分析工具能做一半另一半我交给 Codex2.1 图形化扫描工具能告诉你哪里大但说不清能不能删市面上扫描磁盘占用的图形化工具其实非常多。有些能秒级扫完全盘用色块热力图把大文件直观地画出来有些能按文件类型统计告诉你视频、压缩包、缓存各占多少。以前电脑盘满的时候我也经常用它们看完热力图确实能快速定位到 AppData 这个目录但接下来的问题是热力图只告诉你大不告诉你为什么大。比如你会看到 AppData 里有几十个子目录每个都有几百MB文件名几乎都是 GUID 长相的随机字符串属性提示是系统文件。这个时候扫图工具帮不上任何忙你还是得一个一个去搜目录名确认它属于哪个软件、那个软件现在还在不在用、里面的内容删了会不会出问题。对于一次清理来说这份工作量跟全盘扫描本身差不多大。2.2 Codex 介入后整个工作流从定位延伸到了决策我选择 Codex不是因为扫图工具不好用而是我需要从定位走到决策这一步。Codex 在这种场景下的价值是我可以用自然语言描述需求让它写扫描脚本再把扫描输出贴回去让它按目录名分析归属、给出清理建议最后还能让它把建议整理成一份带风险等级的操作清单。整个过程相当于请了一个熟悉系统目录结构的助手而不是只给我一张热力图。实际用下来这个工作流是先告诉 Codex 我要分析%USERPROFILE%\AppData下每个一级和二级目录的占用请生成一个 PowerShell 脚本跑完拿到占用清单后我再把前几十条输出贴给它问这些目录分别是什么哪些是缓存可以清哪些要小心。它给出的分类结果很快就对应上了我后面要做的清理动作。相比扫图工具这条路径多花了一点时间但得到的是可以直接执行的结论。2.3 如果你也想复刻需要准备什么如果你想照这个思路复现准备条件其实很低。一台装好系统的电脑一个能跑 PowerShell 的普通用户权限就行如果目录里有系统级受保护文件用管理员权限打开终端再跑更稳。另外建议先做好备份意识别想着删就完了——至少确认聊天记录和文档没有被误判为缓存。需要说明的是复刻的核心不是某个固定脚本而是自然语言描述需求让 AI 写代码并分析结果这个方法本身。每台电脑目录结构都不一样应用的缓存分布千差万别直接照抄别人的命令很可能无效。让 Codex 针对你的实际目录结构现场生成才是更可靠的姿势。3. 用 Codex 给 AppData 出账87.81GB 的完整排查记录3.1 第一步生成目录占用统计脚本我给 Codex 的需求描述大概是这样需要统计一个根目录下所有一级子目录和二级子目录的占用大小按占用降序输出要求能跳过权限错误结果以 GB 为单位保留两位小数。Codex 给我的第一版脚本很朴素就是递归遍历、加总、排序如下$root $env:USERPROFILE\AppData $rows foreach ($dir in Get-ChildItem -LiteralPath $root -Directory -Force -ErrorAction SilentlyContinue) { $sum (Get-ChildItem -LiteralPath $dir.FullName -Recurse -File -Force -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum).Sum if (-not $sum) { $sum 0 } [PSCustomObject]{ 一级目录 $dir.Name 完整路径 $dir.FullName 大小GB [math]::Round($sum / 1GB, 2) } } $rows | Sort-Object 大小GB -Descending | Format-Table -AutoSize这个脚本本身不复杂但它解决了一个关键问题我可以安心地把它丢在那里跑完得到一个不掺个人猜测的数值结果。跑完之后第一层统计就出来了AppData 下面一共有三个一级子目录——Local、Roaming、LocalLow分别占了 69.32GB、12.74GB、5.75GB加起来刚好对得上 87.81GB。第二步我让 Codex 调整脚本把范围缩小到 Local 这一层下逐个二级目录统计。这一步的输出就非常有用了目录名直接把问题来源暴露出来了缓存目录、临时目录、浏览器数据目录全都在榜单前列。3.2 跑扫描时踩到的三个坑第一个坑是 PowerShell 的递归统计对授权问题和长路径特别敏感。如果脚本不加-ErrorAction SilentlyContinue遇到受保护目录时整条命令会报错中断如果不处理超长路径一些深层文件会扫不到。好的做法是保持-Force和-ErrorAction配合宁可跳过个别目录也不能让整个统计中断。第二个坑是范围问题。第一次跑扫描的时候我以为 AppData 已经是全部了其实只扫了当前用户目录。后来才发现有些软件的公共数据放在所有用户共享的目录里也有几十个GB的缓存。如果只想定位当前用户的 C 盘问题那扫 AppData 就够但如果想全面排查记得把公共目录也加进去。第三个坑是等待耐心问题。AppData 里动辄十几万个小文件即使脚本逻辑没问题跑完也要几分钟。我第一版没加进度输出跑起来之后完全不知道是正常在跑还是卡死了。后来让 Codex 加了一个简单的时间点打印每处理完一个二级目录就输出一行才确定脚本确实在干活。3.3 让 Codex 把输出变成清理建议清单拿到占用清单之后我没有自己一行一行去搜目录名直接把前 40 行输出贴给了 Codex让它按目录名判断每个目录的性质并给出风险等级。这一步的产出非常关键它把所有目录分成了三类——确定是缓存的、可能是数据的、不确定的并且针对每一类给出了建议动作。这时候我才真正下定决心去清理而不是继续盯着那个 87.81GB 的数字发呆。需要注意的是AI 给出的目录归属判断能作为参考但最终动手前还是要自己验证一下。比如某个名为 Cache 的目录你说它是缓存没问题但在删之前我会先确认对应软件没有在运行否则文件还在被占用删到一半报错是小事搞出索引损坏就麻烦了。我建议把 AI 当作战术地图而不是免死金牌。4. AppData 里的大头87.81GB 到底是谁吃掉的4.1 账本明细最后输出的占用量级大概是这样一张表数值是清理前的快照一级目录 / 二级目录大小主要内容性质Local\pip\Cache21.3GBPython 包下载缓存whl 文件缓存Local\浏览器 User Data15.2GB网页缓存、站点数据、会话文件缓存数据Local\聊天软件10.6GB聊天文件、头像、历史记录附件数据混合Local\npm-cache9.7GBnpm 包缓存_cacache缓存Local\Temp7.4GB应用临时文件、更新残留垃圾为主Roaming\开发工具 logs4.9GB运行日志、崩溃转储日志LocalLow5.75GB低权限应用的数据目录混合其他零散目录13.96GB几十个小目录混合这些数值相加是 87.81GB和前面对得上。把这张表拿给任何一个人看问题都不再是哪里大而是哪些能清。这正是后面章节要解决的问题。4.2 看懂目录名缓存、数据、垃圾是怎么区分的很多人不敢动 AppData是因为看不懂目录。其实把命名规律讲清楚之后难度会立刻下降。含 Cache、Temp、Logs、CrashDumps 这类词的目录绝大多数是缓存和临时产物删掉之后对应软件会重建或重新下载含 User Data、Roaming 下的一些软件目录往往是配置和用户数据删了可能造成设置丢失而名字是 GUID 或哈希字符串的目录则需要靠它所在的父目录来判断归属。这就像整理房间Cache 是茶几上吃了一半的零食Temp 是垃圾桶里的包装纸User Data 是衣柜里叠好的衣服。零食扔掉可以再买包装纸扫掉无所谓衣服就不能随便丢了。搞清楚这个分类AppData 看起来就不再是黑盒子而是一间有迹可循的杂物房。4.3 为什么它们会悄悄膨胀到几十个GB缓存从设计上说只是为了加速为什么会膨胀到几十GB原因是大多数应用只往缓存里写不负责在空间紧张时自动清理。包管理器下载的每个版本都会存一份副本版本更新一次旧版本也不会立即清除浏览器为了秒开历史页面把每个图片、视频、脚本文件都留了本地副本。日积月累它们就长成了庞然大物。另外一个平时注意不到的因素是崩溃转储和日志。开发工具一旦频繁崩溃一个 dump 文件就有几个GB日志更是几十MB地增长。这些文件对系统运行没有用只是证明软件挂过但对开发者排查问题有点价值。我的建议是先归档再删除别直接扔进回收站了事。5. 释放空间的操作顺序先安全区再谨慎区最后上高压线5.1 安全区随手能清的几样安全区指的是删掉后一定会重建的内容主要对应表里的缓存类目录和临时目录。我自己操作时优先做了这几件事先关掉开发工具和浏览器然后清空 Temp 目录接着用命令清理两个包管理器缓存最后启动浏览器自带的清除缓存功能。# 清理 pip 下载缓存 pip cache purge # 清理 npm 缓存 npm cache clean --force浏览器缓存的清理路径不在命令行一般是在设置里找清除浏览数据勾选缓存文件。这一步会释放掉 User Data 下那 15.2GB 里的大部分。清理之后验证一下直接把整个缓存目录从磁盘上移除然后打开软件让它重新生成。实测下来这些操作做完C盘可用空间立刻从 3.2GB 涨到了 55GB 左右。注意清理缓存之前先确认对应软件已经退出。文件被占用时删除会失败反复报错只会浪费时间。5.2 谨慎区聊天记录、开发工具日志要留个心眼聊天软件那 10.6GB 不是单纯缓存里面混着接收文件、头像、历史记录附件。如果直接删目录可能把没有备份的聊天文件一起带走。稳妥做法是打开软件自带的存储管理按会话或文件类型清理而不是到 AppData 目录里用文件管理器硬删。这一点是我在清理同类问题时踩过坑才总结出来的。开发工具日志有 4.9GB清理前最好先看一眼最近几天的日志有没有报警信息。对于崩溃转储可以保留最近一两个用于排查其余打包压缩或直接删除。日志文件适合归档不适合全删因为下一次排查问题的时候你可能真的需要它们。5.3 高压线这些删了真会出事有几类东西无论如何都不能直接进回收站。AppData\Local 和 AppData\Roaming 这两个一级目录本身不能整块删除——这是无数软件的配置所在地删了等于所有应用恢复出厂设置。软件的 User Data 目录也不能乱删尤其是有登录态和数据存储的应用。至于系统目录还有 Program Files、ProgramData更不是清理 AppData 问题时应该碰的区域。我还整理了一条基础原则凡是目录名里有 System 字样、位于 AppData 根级、或者你完全不知道它属于什么软件的三无目录都不要为了那几百MB去冒险。宁可让它们继续躺着也不要换来一场随时可能发作的系统故障。6. 清理完最要紧的一件事别再让C盘三天两头发红6.1 给缓存换盘搬家清理只是治标防止再次爆红才是治本。最容易做的就是把常用的包管理器缓存迁移到其他盘。pip 和 npm 都支持自定义缓存目录配置好之后以后下载的缓存从出生开始就在别的盘根本不占用 C 盘。# pip 缓存改到 D 盘 pip config set global.cache-dir D:\pip-cache # npm 缓存改到 D 盘 npm config set cache D:\npm-cache浏览器和数据类软件如果支持自定义存储路径也在设置里把缓存位置改到其他盘。这样操作之后C盘不再是所有临时数据的默认集中营飘红频率会大大下降。6.2 把扫描脚本留着每月跑一次第3章里让 Codex 生成的脚本清完之后我并没有扔掉而是保存成了 .ps1 文件。以后每个月 C 盘吃紧的时候我都会重新跑一遍看看到底是哪个目录又长起来了。有了历史数据之后你会发现某个目录的占用趋势是有规律的——比如每次安装大项目后 npm 缓存会猛涨几GB隔一段时间清理一次就够。为了让脚本更好用我让 Codex 又加了两个功能末尾输出一个总占用行以及把结果同时写到文本文件里。这样既能在终端直接看也能保留一份可对比的记录。一个十几行的脚本带来的长期价值比任何一次性清理工具都大。6.3 从救火到巡检的思维转变这次清理给我最大的感触是C盘空间管理不该是爆红才处理的救火行为而应该是定期看数据、按类别处理的巡检行为。很多用户把大量精力花在下载各种清理工具上其实不如花十分钟跑一次自己生成的扫描脚本再用常识判断一下哪些目录属于哪些应用该清就清该留就留。我也不建议为了省空间去做高风险操作比如清理系统核心组件或者压缩系统目录。与其冒风险省出几GB不如好好规划缓存位置、定期清理几次效果稳定且不伤系统。最后说点这次实操的体会。排查 AppData 这 87.81GB 的过程看起来是跟磁盘空间搏斗实际上更像是在跟不了解搏斗。以前遇到 C 盘爆红我的第一反应是找各种清理工具一键清除后来发现那些工具能清的永远只是一小部分。用 Codex 把目录占用算清楚之后很多以前不敢动的文件夹变得可以理解了它是缓存、是日志、还是数据一眼就能分辨该删该留自然就有了依据。我现在仍然会定期跑一遍扫描脚本但它更多是用来发现问题真正解决问题靠的是建立了按类别清理的节奏。如果你也在被 C 盘爆红困扰我建议先别急着删任何东西先找个方法把大目录的账算清楚再说。

C盘爆红不用怕：用Codex精准清理AppData释放87GB空间

相关推荐

微信小程序投票系统毕设源码与数据库实战指南

个人智能体（Personal Agent）火爆背后：从“交互工具”到“代行中介”，重塑决策链的商业新博弈

基于FCN的腹部CT脊椎分割实战：从数据预处理到推理后处理

更多资讯

深度学习加速核心：GEMM优化从分块到TensorCore的实战解析

XPath Helper插件实战：从元素定位到Python爬虫提取的完整指南

DeepSeek部署实战：从选型、量化到调参与排障

AI 早报 10.10｜GPT-6.1 Sol 提速 8 倍

如何在 Android 上运行 OpenClaw？兼容性补丁全剖析：glibc-compat.js、argon2 桩、systemctl 桩与硬链接补丁

Docker本地部署Home Assistant：从零搭建私有智能家居平台

今日更新

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？