C盘爆红这种事经历过一次就再也不想经历。我前两天正写着代码系统突然弹窗提示 C 盘空间不足磁盘剩余居然只剩不到 1GB。习惯性点开“此电脑”看到 C 盘那一整条红色第一反应是打开应用列表准备卸载软件但后来我忍住了。因为我用 Codex 先把磁盘占用算了一遍结果发现仅 AppData 目录就占掉了 87.81GB——这已经不是靠卸载几个软件能解决的事了。这篇文章记录我怎么用 Codex 一步步定位到这个巨无霸目录以及后续安全清理的完整思路希望给你一条不用乱删也能救回空间的可行路径。1. 磁盘满格时的第一反应为什么“乱删”是最危险的动作1.1 卸载软件和手动删文件的隐性成本很多人拿到“C盘爆红”的第一反应就是去“设置 - 应用”里挨个看把看起来体积很大的软件卸载掉。但这里有个认知陷阱很多软件的真正体积大头根本不在安装目录而在用户数据目录。拿我身边的例子来说某个图形设计软件的缓存文件夹动辄几十GB一堆用 Electron 框架做的桌面应用本质上是套了个壳的浏览器它们的数据、缓存、LocalStorage 全在 AppData 里还有开发环境里的包管理器、容器镜像也都会往用户目录塞东西。你把主程序卸载了数据依然躺在那空间不会回来多少反而丢了卸载前本可以保留的配置。更危险的是手动去 AppData 里删文件夹。AppData 这个目录名看起来像“应用程序数据”但里面不光是缓存还有大量应用的配置、账号凭证、数据库文件。我吃过一次亏为了省空间我直接删了某开发工具的缓存目录结果启动后它的登录态全没了环境配置全被重置前前后后重新配了三个小时。所以越是在空间告急的时候越不能靠“看着像垃圾就删”的直觉来解决问题。1.2 先量化再清理空间分析是唯一正确入口磁盘清理有一个朴素但高效的原则先知道谁占了大头再决定动谁。你脑子里猜“是不是游戏装太多”或者“下载文件夹太满”往往跟事实差距很大。Windows 自带的磁盘清理只能清系统临时文件第三方管家给你一屏“垃圾”可真正的大块头却藏在 AppData、Windows.old、System Volume Information 这类系统保护目录里。与其盲猜不如先把所有目录尺寸拉一份清单按大小排序一眼看到 87.81GB 的 AppData 排在最前面。这一步就叫“量化”。量化之后清理就成了一个明确的目标行为而不是一场赌上文件安全的冒险。2. 为什么我选 Codex 而不是直接装一个 WinDirStat2.1 Codex 是什么它凭什么能帮到磁盘分析我必须先说明我这里说的“Codex”不是某个神秘工具而是一个 AI 编程助手。你跟它说人话它给你写代码。比如“写一个 PowerShell 脚本扫描 AppData 下每个子目录的体积按大小排序输出”它就会返回一段可以直接运行的脚本还会解释每段代码在干嘛。对于不熟悉命令行的人来说这比查文档快得多对我来说它最大的价值是能让我在五分钟内拿到一个可重复执行的报表而不是一次性用完就扔。你可能觉得这并不是什么不可替代的能力。确实随便一个搜索引擎也能搜到类似的脚本。但 Codex 强在可以连续对话你告诉它“脚本跑得太慢了能不能用 .NET 接口”它就改写一版你再告诉它“帮我排除权限拒绝的目录”它又会更新。这种根据现场反馈持续调整的能力才是我选择它的原因。2.2 一条提问换来一份定制型扫描脚本我当时在终端里输入的问题很直接“写一个 PowerShell 脚本遍历 C:\Users用户名\AppData 下面两层目录统计每个目录大小过滤出超过 1GB 的按大小倒序排列并把结果导出成 CSV。”Codex 给了我一版脚本里面用到了 Get-ChildItem 和 Measure-Object逻辑没错但一跑我就发现要命——AppData 里的文件数量多到爆炸递归遍历的耗时完全是分钟级别的。后来我请它换成 .NET 的 DirectoryInfo 和 GetFiles 接口速度快了将近一倍。这其实是很多教程不会说的点PowerShell 写起来简单但天然慢.NET 接口写起来繁琐但性能更可靠。Codex 的价值就是把这些选择背后的 trade-off 摆到你面前让你根据场景选。2.3 脚本方案与图形化工具对比各有各的底牌图形化工具有没有用有。WinDirStat、WizTree、TreeSize 我都用过尤其是 WizTree直接读取 NTFS 的 MFT几秒钟就能把整个磁盘的目录占比图刷出来看着大片色块视觉冲击力很强。但它们有个短板交互式操作无法自动化你很难把“扫描一次、输出报表”这个动作打包成脚本下次直接运行。而 Codex 给我的 .ps1 脚本我存成文件以后每个月双击一下就能得到新的报表甚至还能接上任务计划程序定时跑。所以我的选择逻辑很简单想快速扫一眼全局用图形工具想做一个可复用的确认流程用脚本。这次我的目标不是“随便看看”而是“定量定位 AppData 里的空间刺客”所以脚本是更扎实的方案。3. 完整实操从运行脚本到锁定 AppData 87.81GB 的现场记录3.1 第一步先扫整个用户目录看到 AppData 异常我并没有一上来就直奔 AppData。因为我担心 AppData 只是冰山一角用户目录的其他位置也可能藏着大货。所以第一步我让 Codex 生成的是扫描 C:\Users\用户名 下各个一级目录的体积。这里分享一版可用的脚本但不是性能最优版重点是让你看清思路$base $env:USERPROFILE Get-ChildItem -Path $base -Directory -Force -ErrorAction SilentlyContinue | ForEach-Object { $folderSize 0 $files (Get-ChildItem -Path $_.FullName -Recurse -File -Force -ErrorAction SilentlyContinue) $folderSize ($files | Measure-Object -Property Length -Sum).Sum [PSCustomObject]{ 目录 $_.Name 大小GB [math]::Round($folderSize / 1GB, 3) 文件数 $files.Count } } | Sort-Object 大小GB -Descending | Format-Table -AutoSize注意这个版本确实慢。AppData 里的文件可能几十万个在传统机械硬盘上跑一次要十分钟。如果你不想等可以用 robocopy 的/L /NJH /NJS参数来模拟复制并统计字节或者让 Codex 帮你改写为 .NET 的DirectoryInfo.EnumerateFiles版本。但第一次跑为了确认流程慢一点没关系。当时输出结果出乎意料但又在情理之中OneDrive 大概 20GBDownloads 5GB而 AppData 直接是 87.81GB断层式第一。这个数字立刻让我意识到真正要处理的不是系统盘上的安装程序而是用户数据目录里那些日积月累的缓存。3.2 第二步拆解 AppData 的三大子目录找到真正的大头AppData 底下有三个目录Local、Roaming、LocalLow。很多人不知道它们有什么区别。简单说Local 按机器存储不会跟着账户漫游Roaming 会同步到域账户/微软账户某些软件会把配置放这里LocalLow 是给低权限进程比如浏览器沙箱用的数据目录。清理前最好搞清楚每个目录下是什么因为 Roaming 里很可能有软件的配置和聊天记录不能一股脑删。我分别统计了三个目录的大小结果 Local 占了大头剩下 Roaming 和 LocalLow 占了一小部分。于是继续深入 Local 的子目录$localPath $env:USERPROFILE\AppData\Local Get-ChildItem -Path $localPath -Directory -Force -ErrorAction SilentlyContinue | ForEach-Object { $size (Get-ChildItem -Path $_.FullName -Recurse -File -Force -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum).Sum [PSCustomObject]{ 目录 $_.Name 大小GB [math]::Round($size / 1GB, 3) } } | Sort-Object 大小GB -Descending | Select-Object -First 15 | Format-Table -AutoSize扫描结果显示排名靠前的几个目录分别是某个容器工具的数据目录40.2GB某个基于 Electron 的桌面应用缓存18.3GB系统临时文件目录 Temp8.4GB某个聊天工具的本地消息存储15.7GB一个浏览器组件的缓存5.0GB。到这里87.81GB 的构成已经清楚了。原来大头根本不在“安装软件”的 Program Files而在这些看似隐蔽的用户缓存目录。这也再次印证了那一句话不清扫你永远不知道空间去哪了。3.3 第三步让 Codex 把“安全可删”和“谨慎保留”分类定位到具体目录后下一步不是马上删而是做风险评估。我把上一步扫描出来的目录列表直接发给 Codex要求它按三个标签分类可安全清理缓存、临时文件、更新包、需要谨慎处理可能包含配置、登录状态、几乎不可删系统关键数据。它给出的表格虽然不能百分百准确但给了我一个很好的拾遗补漏方向。比如它提醒我注意某个容器工具的数据目录可能不是纯缓存而是虚拟磁盘需要去工具面板里检查是否还有创建中的容器。我还按它的建议优先清了 Temp 目录下的旧文件然后是 Electron 应用的 Cache、Code Cache、GPUCache 这类明确标记为缓存的地方。这种分类思考的习惯比单纯删掉几十GB意义大得多因为它能防止下次再积累。4. AppData 中常见的空间大户以及哪些能碰哪些不能碰4.1 这些文件夹最容易膨胀根据这次排查我总结了 AppData 里最容易膨胀的几类目录类型你在自己电脑上八成也能遇到软件缓存目录。浏览器、影音类应用、开发工具为了方便下次打开更快会把大量图片、脚本、视频片段缓存到磁盘。这类缓存删了会自动重建不需要担心。日志文件目录。应用出错时的崩溃日志、配置文件里的 trace 日志日积月累也很可观。本地数据库。聊天工具的消息记录、搜索软件的索引、某些软件的本地 NoSQL 数据库会随使用时间快速增长。安装包缓存。很多下载器会把新版本安装包先放到 AppData 里更新完成后不自动删除你会莫名其妙发现多出好几个G。开发类工具的数据目录。比如容器镜像、虚拟机磁盘、包管理器的全局缓存这是现代开发机上最容易被忽视的庞然大物。Windows 传递优化文件。它的正式名字叫 Delivery Optimization用于系统更新分发的缓存有时会占好几个G但通常在 C:\Windows\SoftwareDistribution\Download 下个别时候也会在用户目录中留下临时副本。4.2 我的 87.81GB 是怎么组成的这次清理前我做了一张表格记录现场数据给你参考路径大小属性AppData\Local\容器工具数据目录40.2 GB虚拟磁盘需应用内确认AppData\Roaming\某聊天工具15.7 GB消息记录缓存不能直接删整个目录AppData\Local\某 Electron 应用18.3 GB主要是 Cache可清理AppData\Local\Temp8.4 GB临时文件可清理AppData\LocalLow\某浏览器组件5.0 GB缓存可清理其他零散目录0.19 GB合计很少加起来正好在 87.8GB 左右。最终我通过应用内清理和手动删除缓存把整个 AppData 降到了 41.2GB释放 46.6GB。特别说明一下那个占 40.2GB 的容器工具数据目录我看了一眼里面没有正在使用的容器就直接在工具面板里执行了清理操作释放了约 33GB聊天工具我只清了图片和文件缓存保留了文字消息记录所以节省有限。这样总结下来效果依然显著。4.3 红线目录这些位置千万别手滑清理的过程里有几种目录我建议你无论如何不要轻易去动AppData\Local\Packages之下是 UWP/商店应用的独立数据空间。目录名是一串乱码里面保存着应用的状态和用户数据删掉可能导致应用损坏或登录丢失。AppData\Roaming\Microsoft\Crypto等文件夹里存有密钥相关文件和数字证书、加密文件关系很大动它们等于自找麻烦。所有你叫不出名字但包含 “wallet”“vault”“token” 字样的目录大概率保存了敏感凭证删了以后轻则软件要重新登录重则本地加密数据无法解密。正在运行的软件所对应的 AppData 目录即使只是删 Cache 子目录也最好先把进程退出。否则文件被锁删一半不仅清不干净还可能导致软件下次启动时数据错乱。5. 五个让我少踩坑的安全清理原则实操心得5.1 先关闭应用再清理对应目录这是所有清理动作里最关键的一条。某个应用正在运行时它会在后台频繁读写 AppData 下的文件你在这个时段删除要么报“文件正在使用”要么删完后进程又把缓存写回一部分结果就是删了等于没删。更糟的是部分应用在运行时会检测到数据目录被改动启动时可能触发恢复流程。正确做法是先在托盘区退出应用再打开任务管理器确认没有相关进程残留最后才去动文件夹。5.2 能走应用内清理的就不要手动删AppData 里很多目录结构并不透明比如某个软件的 “Local Storage” 文件夹你看着像缓存实际上是它的核心数据库。这时贸然删除后果不可预测。对比起来几乎所有主流应用都会在设置里提供“清除缓存/释放空间”的功能那个入口经过了开发者测试知道哪些文件可以安全删除。所以我现在的习惯是优先点软件设置里的清理按钮只有那些没有设置入口的缓存目录才考虑手动删。5.3 使用“移动”代替“删除”作为过渡方案如果你对一个目录是不是安全没把握我强烈推荐一个技巧不要直接删除而是把整个目录移动到另一个盘或者改名比如把Temp改成Temp_old。这样等于先做一个软删除如果接下来几天应用运行正常系统也没报错再回去把它清空如果有问题你还可以一秒还原。这次清那个 Electron 应用的缓存目录我就是先把它改名重启应用确认能正常创建新缓存后才把旧目录删掉的。这个技巧帮我避免过至少两次灾难性误删。5.4 警惕“即点即删”工具给出的“全部清理”按钮有时候我为了省事也会用系统清理工具但从来不会直接点“一键清理”。因为很多清理工具默认勾选的项里可能包含“缩略图缓存”“预读文件”“崩溃转储”这些删了影响不大但如果你不手动展开它很可能把“应用程序缓存”“用户临时目录里的登录态残留”也一并清理。所以我建议用工具清理时打开高级选项把任何涉及“用户配置”“Application Data”的选项先取消勾选只保留 Windows 临时文件、回收站、缩略图这类无争议项。5.5 每次清理后用脚本复测一次清理完成并不是终点。我最常做的一步是重新跑一遍最初的扫描脚本看 AppData 总大小到底降了多少。这样能立刻发现有没有目录被占用导致没清掉也能验证清理有没有误伤。如果空间没怎么下降说明某个进程还在偷偷占用写入这时候就要去查具体进程。如果空间下降明显系统运行也正常那这次清理才算真正完成。6. 常见问题与避坑速查表6.1 为什么脚本统计的大小和磁盘属性对不上很多朋友第一次跑完脚本会困惑明明 Windows 资源管理器里显示某个文件夹占 5GB脚本统计结果却只有 3GB。这有几种原因一是权限部分子目录访问被拒绝脚本默认跳过二是 NTFS 的压缩和硬链接文件大小和占用磁盘空间是两回事三是有些文件正在被占用读取不到全部内容。所以脚本结果只能看作“可观测大小的近似值”真实大小以磁盘属性为准但做排序和趋势判断完全够用。6.2 删除时提示“文件正在使用”怎么处理如果提示正在使用先打开“资源监视器”的 CPU 标签在“关联的句柄”里搜索文件路径能定位是哪个进程然后退出该进程或重启系统再删。更稳妥的办法是把删除操作放到安全模式里执行因为安全模式不会加载大量第三方进程文件锁定情况会少很多。但一些系统级文件即使安全模式也不能删那就别硬删确认文件路径后再想别的办法。6.3 出现了“unexpected error”怎么办如果一个按键或一条命令报错先看错误信息里的路径。如果是权限错误右键“以管理员身份运行”PowerShell如果是路径过长改用 robocopy 或者使用\\?\前缀如果是脚本语法问题把报错贴给 Codex 让它修。别自己钻进牛角尖AI 助手这时候就是给你查报错用的。6.4 Codex 生成的脚本跑挂问题可能出在软链接AppData 下有些目录是软链接junction比如某些旧版本应用的迁移目录。递归遍历时脚本可能顺着链接进入循环或者无限扩大扫描范围。解决办法是跳过 ReparsePoint也就是在 Get-ChildItem 里加-Attributes !ReparsePoint或者用 .NET 的FileAttributes.ReparsePoint做过滤。这不是新手容易想到的坑但踩过一次你就记住了。6.5 为什么清理完 Temp 后空间只降了一点点Temp 目录里很多文件正被运行中的进程锁定无法删除另外系统临时文件也可能在别的路径比如C:\Windows\Temp和C:\Windows\SoftwareDistribution\Download。要清 Windows 更新缓存需要管理员身份打开“磁盘清理”选择“清理系统文件”它才会处理系统侧临时文件。用户目录的 Temp 只是其中一部分。最后再分享一个小习惯这次 C 盘爆红给我留下的并不只是一个清理经验更重要的是养成了“定期量化”的习惯。现在我每个月月初都会跑一遍那个由 Codex 生成的扫描脚本把新增的缓存目录列出来看一眼有没有突然膨胀的大块头。这个过程基本就是双击脚本、看输出顶多五分钟。偶尔借助 Codex 更新一下脚本逻辑增加对新软件的识别规则让整个检查流程越来越顺手。清理磁盘这件事真不像很多人想象的那么玄它就像给屋子做大扫除先看清哪个角落堆了东西再决定扔掉什么、留下什么。希望这次 87.81GB 的经历也能帮你下次面对红色 C 盘时多一分从容少一分冲动。