C盘爆红的时候大多数人的第一反应是找“看起来很大”的文件夹点进去删我见过有人把 AppData 直接打开始盲删结果当天电脑变得越来越慢甚至软件登录态全丢。我手上这台经常跑编译和容器镜像的机器同样遇到C盘告急这次我没有急着动手删而是用 Codex 生成脚本把用户目录扫了一遍发现光 AppData 就占掉 87.81GB。问题一旦量化就好办了到底是哪些软件、哪些缓存、哪些残留撑出来的全部列出来再决定动哪类比对着文件夹名猜要靠谱得多。这篇文章就把从“爆红”到“瘦回来”的整条路写清楚无论是刚接触系统清理的新手还是想抄脚本的开发者都能按着走一遍。1. 先看清楚 AppData 是什么再决定要不要删1.1 AppData 不是单纯“缓存”它是三个性质完全不同的房间我第一次听说 AppData 的时候也以为它就是个系统缓存目录清掉无所谓。后来才发现这个判断错得很离谱。AppData 下有三个固定子目录Local、LocalLow、Roaming分别对应本机数据、低完整性数据和可漫游数据。用一个不太严谨的生活类比Local 是你的床头柜东西放这里只有这台电脑看得到通常也最重LocalLow 像一个加了护栏的储物柜只有最低权限的程序能往里放东西主要为了隔离风险Roaming 则像一个随身背包配置和数据会被同步到其他登录同一账号的设备上。所以它并不是“缓存”两个字能概括的。浏览器缓存、临时文件确实在里面但软件配置、账号凭据、本地数据库、安装后的组件信息、游戏存档统统也混在里面。删之前不弄清这一点后果就像把床头柜里夹着银行卡的日记本一起扔了。1.2 乱删 AppData 的四种典型后果我不是想吓唬谁但盲删之后大概率会遇到这几种问题软件恢复初始状态重新登录还好但本地历史记录、自定义设置全没了某些桌面包管理工具或开发环境的“已安装信息”被删掉点卸载直接报错说找不到组件账号凭据被清掉重新打开软件时要求再做一遍安全验证最隐蔽的一种程序根本不报错但某个功能悄悄失效很久之后才发现。这些问题的共同点在于“不提示”。系统不会因为 AppData 缺了某个子目录而蓝屏但每个软件的行为都可能开始变得奇怪。尤其 Roaming 里那些带登录态的数据删了之后等于把你和账号之间搭的桥拆了。真正安全的方向不是“删 AppData”而是“分清里面哪些是给某几类缓存准备的只处理确凿可以重建的那部分”。2. 不靠肉眼让 Codex 把盘里的账算明白2.1 为什么不能靠资源管理器一层层点很多人觉得手动翻文件夹就能找到大头其实效率极低。资源管理器显示文件夹大小需要一层层递归统计小文件数量一多点哪个目录都卡半天。更关键是容易漏掉隐藏目录和没有访问权限的子目录最后统计出来一个严重偏低、误导自己的数字。所以我的第一步不是打开我的电脑而是把磁盘扫描这件事“外包”出去。这里提一个判断原则直接看全局报告比凭感觉去点某个“疑似很大”的目录重要得多。先全局后局部目标的顺序是 C 盘 → 用户目录 → AppData → 具体子目录。2.2 给 Codex 的第一条指令扫出用户目录一级占用现在这种能帮你在终端里写代码的 AI 助手已经不少Codex 是比较顺手的一种。我当时的思路很简单让它生成长扫描脚本我来审查、运行、看结果。给 Codex 的提示词大概是这样的我用的是 Windows 11C 盘快满了。请写一个 PowerShell 脚本 1. 扫描 C:\Users\当前用户 路径下所有一级子目录包含隐藏目录 2. 统计每个目录的实际占用大小 3. 按大小从大到小排序 4. 单位转换为 GB保留两位小数 5. 遇到无权限目录时跳过不要中断。Codex 返回的脚本经过调整后核心部分是这样function Get-FolderSize { param([string]$Path) $bytes (Get-ChildItem $Path -Recurse -Force -File -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum).Sum if ($null -eq $bytes) { return 0 } return [math]::Round($bytes / 1GB, 2) } $userRoot $env:USERPROFILE Get-ChildItem $userRoot -Directory -Force -ErrorAction SilentlyContinue | ForEach-Object { [PSCustomObject]{ 目录 $_.FullName 大小GB Get-FolderSize -Path $_.FullName } } | Sort-Object 大小GB -Descending | Format-Table -AutoSize这段代码有一个细节很容易被初学者忽略Measure-Object在空目录或权限全被跳过的目录上返回的 Sum 可能是$null直接除 1GB 会报错。所以我让脚本里专门做了一次空值判断这也是把生成代码交给 AI 之后自己必须再核对一遍的原因。我把脚本存成scan-user.ps1右键“使用 PowerShell 运行”。输出结果排在了第一位。当时显示AppData 87.81GB远超其他目录。这里要单独提示一句PowerShell 这种递归统计在文件数量多的目录上并不快可能跑几分钟甚至更久。如果想要秒出结果可以用基于 MFT 记录的磁盘分析工具它们直接读文件系统元数据速度完全不是一个量级。PowerShell 脚本的优势不在“快”而在可复用、可定制后面做成定时监控很顺手。2.3 第二条指令把 AppData 的子目录逐个翻出来全局结果锁定 AppData 后我用 Codex 生成第二份脚本要求把 Local、LocalLow、Roaming 三个目录下的二级文件夹分别统计一遍按大小排序。$base Join-Path $env:USERPROFILE AppData foreach ($top in (Local, LocalLow, Roaming)) { $path Join-Path $base $top Write-Host $top Get-ChildItem $path -Directory -Force -ErrorAction SilentlyContinue | ForEach-Object { [PSCustomObject]{ 目录 $_.Name 大小GB Get-FolderSize -Path $_.FullName } } | Sort-Object 大小GB -Descending | Select-Object -First 15 | Format-Table -AutoSize }运行之后占大头的位置立刻暴露出来。这个动作本身价值很大我把“删什么”的决定从“看到哪个文件夹名字不顺眼”变成了“数据告诉我哪个目录确实有问题”。判断依据不同操作风险完全不一样。这里也想说明白你会问为什么不让 Codex 一步到位生成整个清理脚本我的经验是不要这么做。清理动作涉及删除必须人在中间做判断。AI 负责把“账本”算出来人负责看账本做决定分工明确且安全。3. 87.81GB 到底是怎么堆出来的3.1 常见大类的占比逻辑扫完脚本看到的是具体目录名。为了理解它们我把这些目录按性质归了几类大类典型位置示例体积潜力堆量原因浏览器缓存Chromium 内核浏览器的 Cache、GPUCache、Code Cache可达 10GB 以上缓存策略激进、网页媒体文件反复读写系统临时文件Local\Temp几个 GB 很正常软件异常退出后临时文件不清理包管理器缓存npm、pip、NuGet 等工具的缓存目录非常容易堆到十几 GB每个版本包都下载到本地没有自动淘汰开发环境索引IDE 缓存、编译器缓存的 Cache 目录视项目数量而定索引和缓存不会自动删除旧版本桌面同步成果云同步工具的本地副本可能非常大同步默认保留所有文件的本地版本崩溃转储与错误报告CrashDumps、错误报告目录几 GB 时常出现崩溃文件每个都很大系统很少自动清Electron 类应用残留各种装包较重的桌面客户端容易被忽视更新后旧版本文件不清理、缓存重复用把 87.81GB 拆到这些类别里基本可以解释绝大部分体积。平时大家最容易忽略的不是某一类而是“好几类叠加”的效应浏览器几 GB、包缓存几 GB、IDE 索引几 GB、崩溃转储几 GB加到一起就爆了。3.2 开发者机器尤其容易“中招”的区域我手上这台机器长期跑开发所以 AppData 里开发相关的缓存占了很大比例。比较典型的有几类npm 缓存在 Roaming 下历史版本装多了之后体积很稳定地膨胀pip 缓存集中在 Local 下每个轮子包都留一份时间一长数量惊人NuGet 缓存只要拉过不同版本项目的依赖就会持续增长JetBrains 系的 IDE 把索引和缓存直接放在 Local 下一个项目的索引体积不大架不住项目多使用容器或者虚拟化工具时有些磁盘镜像文件也会落地到 AppData 相关目录这种通常单个就很大。如果你是个人电脑使用者而非开发者上面的内容可以不看但要记住一个结论AppData 堆积不是某一个软件的问题而是“所有软件都在往这里塞东西”的长期结果。市面上没有任何一个系统功能会自动把所有缓存清理干净指望系统自己瘦身不现实。3.3 某些桌面客户的“影分身”问题还有一个比较容易忽视的来源同一个软件随着版本更新会在本机留下多份旧资产。特别是基于 Chromium 的那类桌面客户端看似只装了一个软件实际每个版本都自带一套浏览器核心内核和对应缓存。软件升级时旧组件没有彻底移除长期累积下来一个软件占掉数 GB 很常见。这种目录的特征是名字里往往带着软件厂商的名称还可能有Temp、Cache、Index后缀位置在 Local 下。碰到这种目录不要在软件运行的时候去删正确做法是彻底退出软件、卸载旧版本残留再考虑清理对应缓存。4. 动手前的分级清理规则4.1 不是所有缓存都一个处理法很多人问过我那到底哪些能删我习惯把 AppData 里成员按风险分成三档处理级别代表内容操作方式主要风险绿色档Local\Temp、崩溃转储、缩略图缓存、明确可重建的浏览器缓存直接清理很低最多是首次访问稍慢黄色档包管理缓存、IDE 索引、桌面聊天软件的文件接收缓存用软件自身命令或完整退出后清理中等有些需要重建索引或重新登录红色档账号凭据、本地数据库、Roaming 下的配置和存档、云同步的本地副本原则上不动或迁移到其他盘高删了登录态丢失、数据可能无法恢复一个更直观的判断方法问自己一个问题——如果删掉这个文件夹下次打开软件时它是“自动重新生成”还是“找你要东西”前者属于绿色或黄色档后者基本是红色档。凡是要输入账号密码、重新扫码、重新激活才能恢复的东西都属于不能乱动的范围。4.2 用系统自带功能先做一轮“安全清空”不想碰命令行的人也可以先把系统和软件的“自动清理开关”打开。Windows 自带的存储感知功能可以设置定期清理临时文件和回收站这一步能安全释放一部分空间。我实际使用时发现存储感知清理比较保守适合日常维护不适合救急。真正已经爆红的情况下建议先跑一遍磁盘清理工具勾选“临时文件”“Windows 更新清理”“缩略图”这几项。正在被占用的文件不会删掉所以安全性较高。注意清洁完系统部分后再次运行扫描脚本看效果。你会发现系统部分清出来的空间可能只有几 GB大头依然在 AppData 的各种缓存里。这说明 AppData 的账还是要回到 AppData 内部去算。4.3 命令行删除时的两个习惯如果确认某个绿色档目录要清理直接在 PowerShell 里执行删除是最高效的。但我有两个习惯值得分享第一先退出相关软件再删缓存。文件被占用时删除会报错强行跳过占用文件又会留下尾巴下次扫描又是一次残羹冷炙。第二删除前把目标路径用Test-Path验证一次。命令行少打一个斜杠或者输错一个子目录名后果完全不一样。安全起见我习惯先输出一遍路径再执行$target Join-Path $env:LOCALAPPDATA Temp Write-Host 准备清理$target Get-ChildItem $target -Force -ErrorAction SilentlyContinue | Remove-Item -Recurse -Force -ErrorAction SilentlyContinue这条命令的语义是“清空 Temp 里的所有内容”而不是删除 Temp 文件夹本身。很多教程会直接建议删整个 Temp 目录系统虽然会自动重建但我认为没有意义去冒这个险。5. 完整走一遍从爆红到恢复健康的操作顺序5.1 动手之前十分钟的“心理备份”开始大范围清理之前我会先花十分钟做一件事想清楚这个软件如果失效我能不能接受或者有没有低成本的重建路径。不用做到 100% 可恢复重点是避免“情绪化清理”。比如某个缓存目录看起来很大但如果它对应着几十个项目的本地索引删完以后 IDE 重新索引的时间可能长达半小时这个时间成本也是真实的。不是不能删而是要有心理准备。我自己的建议排序是先做系统级临时文件清理再做浏览器类缓存再做开发工具缓存最后才考虑动其他顺手能清的内容。碰到拿不准的目录宁可不删也不要赌。磁盘空间虽然是刚需但安全才是前提。5.2 一档一档来每步都记录结果我当时执行的顺序是运行磁盘清理清除 Windows 更新残留、缩略图和回收站释放约 4GB退出所有浏览器进程后清理浏览器缓存相关目录释放约 10GB 左右逐个执行包管理器的官方清理命令释放大头npm 用npm cache clean --forcepnpm 用pnpm store prunepip 用pip cache purgeNuGet 缓存直接通过其自带恢复机制清掉删除对应缓存目录重启 IDE 前清理其 Cache 和 Index 目录这一步让出十多个 GB但首次启动会明显变慢处理崩溃转储和错误报告目录。每一步结束之后我都会再跑一次扫描脚本记录当时的 AppData 大小。这样做的好处是能直观看到哪一步产出最大下次清理时就知道该把时间花在哪了。5.3 注册表、登录态和软件可用性的验证清理后检验很关键。我的验证清单重新打开最常用的几个软件确认不需要重新登录或者扫码验证打开一个稍大的项目确认 IDE 能正常重建索引而不是报错正常重启一次系统确认没有启动项异常再次运行扫描脚本确认 AppData 体积没有“反弹式”暴增。这四条走完清理才算真正结束。严格说清理之后软件重新生成缓存是正常的但如果体积很快恢复到清理前说明某个软件存在疯狂的缓存写入行为那就不是清理能解决的问题而是要考虑调整软件缓存路径或迁移应用数据盘。5.4 这次从 87.81GB 瘦到什么程度整轮安全清理下来AppData 的最终占用降到了二十几 GB 的区间。请理解这不是一个可以照搬的目标每个人装的软件不同清理后的“合理水平”也不同更重要的是“清理前后能解释清楚空间去哪了”。我特别想强调一个结果之外的收获指挥 Codex 生成的扫描脚本保留下来后续每周都能复用。与其每次等 C 盘爆红再救火不如把它变成常规体检。6. 把“盘满预警”变成日常体检6.1 生成一份月度磁盘报告脚本用 Codex 写一个周期性执行的报告脚本很顺手。给它一句话要求每周日扫描一次磁盘和 AppData 的关键子目录把结果输出到一个文本文件超过阈值则给出提醒。# DiskReport.ps1 $reportFile Join-Path $env:USERPROFILE Desktop\磁盘报告.txt $result () $result 系统盘剩余空间 $disk Get-PSDrive C $freeGB [math]::Round($disk.Free / 1GB, 2) $result 剩余空间$freeGB GB $result AppData 总量 $appDataSize Get-FolderSize -Path (Join-Path $env:USERPROFILE AppData) $result AppData 总占用$appDataSize GB $result AppData 下 Top5 大目录 $base Join-Path $env:USERPROFILE AppData Get-ChildItem $base -Directory -Force -ErrorAction SilentlyContinue | ForEach-Object { [PSCustomObject]{ 目录 $_.Name 大小GB Get-FolderSize -Path $_.FullName } } | Sort-Object 大小GB -Descending | Select-Object -First 5 | ForEach-Object { $result $($_.目录) $($_.大小GB) GB } $result | Set-Content -Path $reportFile -Encoding UTF8 if ($freeGB -lt 15) { Write-Host 磁盘空间不足请尽快处理缓存 -ForegroundColor Red }这个脚本要使用之前定义的Get-FolderSize函数所以我会把两个函数放在同一个脚本文件里。再配合一个基础的任务计划让它自律执行schtasks /Create /TN DiskReport /TR powershell -NoProfile -ExecutionPolicy Bypass -File C:\Scripts\DiskReport.ps1 /SC WEEKLY /D SUN /ST 09:00 /F任务计划用一行命令就能建好以后每周日早上窗口会生成一份文本报告不用等到右下角弹警告才难受。6.2 定期报表能帮你发现软件“异常写盘”习惯把磁盘体检固化下来以后另一个价值会慢慢显现你能观察到某些软件的长期写盘趋势。比如某个目录每周增加 2GB表面看似乎无害但一个月就是 8GB半年就是 48GB。有了趋势数据就能提前决定要不要调整软件设置、移动缓存位置或者干脆换一个替代方案。要知道大多数普通用户其实不是死于“某一次爆炸性增长”而是死于长期不作清理的慢性堆积。报表的价值不是减少操作次数而是帮你把问题发现时间提前。把这一套流程走完我对 C 盘爆红这件事的感受变得不太一样了。以前看到系统警告只会焦虑现在反而习惯先跑一遍扫描脚本让 Codex 帮我生成针对性的清理命令再结合数据判断优先级。这里也分享一个个人体会磁盘清理最核心的不是“胆子大”而是“信息全”。信息越透明操作越克制系统越稳定。如果你正在面对一台爆红的机器与其急着删不如先拿脚本把这些数字老老实实列出来看清楚再动手时间反而花得更少结果也更干净。