ARTICLE · INTELLIGENCE

战地情报 · 详情页

来自尧图项目组的一线实战观察与深度解析

C盘爆红不用怕:用Codex定位AppData 87.81GB缓存并安全清理

C盘爆红不用怕:用Codex定位AppData 87.81GB缓存并安全清理 C盘爆红别乱删我用 Codex 查出 AppData 占了 87.81GB。先说结论AppData 不算系统垃圾也不能整个删掉但里面确实藏着一大批可以清理的缓存和日志只是它们平时被隐藏属性挡着在资源管理器里根本看不出个头。上个月我的 C 盘突然飘红系统自带磁盘清理扫了半天没探出多少可删项目后来我用 Codex 走了几轮分析脚本按子目录逐个统计体积才发现C:\Users\你的用户名\AppData下面有一堆缓存加起来到了 87.81 GB。这篇就是把当时的过程完整复盘一遍。适合三种人看一是 C 盘已经红到发紫、不知道从哪下手的新手二是想学会用命令行和 AI 工具做磁盘体检的进阶用户三是被网上所谓“C 盘清理大师”坑过、想回归手动控制的老手。看完你应该能自己复现整个定位、清理、防护流程下次再遇到爆红不用瞎删。1. 别急着点删除先搞懂 AppData 是“杂物间”还是“保险柜”1.1 AppData 到底是什么为什么它最容易被冤枉很多人的第一反应是“既然 AppData 占了 87GB那就把 AppData 删了呗。”这个想法是所有 C 盘清理事故中最常见的一个。AppData 是 Windows 给当前登录用户分配的一块应用数据存放区里面分成三个子目录AppData\Local本地数据通常只对当前用户生效体积最大也是缓存重灾区。AppData\Roaming漫游数据理论上可以在域环境里跟着用户配置文件迁移很多软件的配置、账号信息都放这里。AppData\LocalLow低权限隔离目录主要用于 IE、浏览器插件、部分游戏存档等。你随便删掉整个目录后果通常是软件配置全部重置账号登录态丢失更糟糕的是有些软件会把数据库文件放在这里比如聊天记录、笔记数据、剪辑项目的历史版本删了之后连恢复工具都难救。我的判断标准很简单AppData 里真正能吃大硬盘的是可以再生的缓存而不是不可再生的配置和存档。缓存删了软件下次运行会自动生成配置和存档删了就真的没了。把这两类分清后面清理才有意义。1.2 为什么我会用 Codex 而不是手动翻目录手动翻目录当然能做但效率太低。在资源管理器里逐层展开Local\...\...每进一层要点一下属性看大小看两三个目录就会失去耐心。而且很多缓存目录没有直观大小的刚需属性计算又慢尤其是那种几百 MB 起步的目录稍大点就得转圈几秒钟。Codex 这类编程助手的价值在于你给它一个明确的“统计体积并排序”目标它能在几秒内生成一段 PowerShell 或批处理脚本把整个 AppData 的一级子目录大小全部列出来。你不用手写语法也不用记那些冷门的 cmdlet 参数只需要审查它给出的脚本逻辑确认没有删除动作然后放到终端里跑。我强调一句Codex 是帮你写脚本、分析和定位的不是替你做决定的。最后删什么、保留什么必须由人判断。整个流程里人负责策略工具负责跑腿这样最安全。1.3 动手之前必须立的几条“军规”每次清理系统盘之前我都会先把规则写出来避免中途手滑第一轮只统计不删除。先看清哪些目录占了空间再决定要不要动。只清理明确可再生的缓存目录Temp、pip cache、npm cache、uv cache、DXCache这类。不碰配置类目录Roaming下的软件配置、Local下的应用数据除非我明确知道它只是缓存。不跨用户目录清理。C:\Users\Administrator\AppData只是其中一个账号有些电脑有多个账号每个账号都有独立缓存别只盯着管理员账号。所有删除操作先做一次“试删”也就是把命令放在 PowerShell 里先以只读方式列出文件清单确认无误后再执行删除。这几条写下来之后后面每一步都有据可查出了问题也知道是从哪一步开始的。2. 清理前的准备安全基线、备份和第一个查询脚本2.1 先把“后悔药”准备好在执行任何删除之前建议至少做三件事。第一打开“系统保护”给 C 盘建一个还原点。方法是在“此电脑”上右键属性进入“系统保护”选择 C 盘点击“配置”开启保护并把磁盘空间使用量调到至少 5%然后点“创建”。还原点建好后就算误删了配置文件也可以回滚。第二把浏览器书签、聊天记录等重要文件单独备份。AppData 里有大量账号登录态清完缓存后重新登录是最轻的后果怕的是某个软件的数据目录被缓存脚本误伤。备份不一定要整个 AppData重点备份Roaming下你离不开的软件配置即可。第三准备一个空的外部 U 盘或移动硬盘。这不是给 AppData 备份用的是为了在系统真出问题、无法正常进系统时能进 PE 或者应急环境把重要资料捞出来。平时用不上最好但有任何磁盘清理操作的时候这个保险必须存在。2.2 用一条 PowerShell 给 AppData 做“体检”准备工作做完后先跑最原始的体积统计。打开 PowerShell不用管理员权限直接执行下面这段$roots ($env:LOCALAPPDATA, $env:APPDATA) foreach ($root in $roots) { Write-Host 扫描目录: $root -ForegroundColor Yellow Get-ChildItem -LiteralPath $root -Directory -Force -ErrorAction SilentlyContinue | ForEach-Object { $size (Get-ChildItem -LiteralPath $_.FullName -Recurse -File -Force -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum).Sum [PSCustomObject]{ 目录 $_.Name 体积MB [math]::Round($size / 1MB, 2) } } | Sort-Object 体积MB -Descending | Select-Object -First 15 | Format-Table -AutoSize }这段代码的作用是分别统计Local和Roaming下一级子目录的体积按大小降序列出前 15 名。-Force 参数是关键它会把隐藏目录和受保护的系统文件也算进去不加这个参数很容易漏掉大块头。第一次运行会特别慢因为要递归遍历大量文件这是正常的。我当时第一次扫全AppData在旧式机械硬盘上跑了差不多十分钟SSD 上会快很多。扫描期间不要去操作那个目录避免文件占用冲突影响统计结果。2.3 给 Codex 的提示词模板只统计不删除脚本手写也行但用 Codex 会快很多。当时我给它发的提示大概是这样你是终端里的脚本助手。我的环境是 Windows 11PowerShell 7。 请帮我分析磁盘占用但不要执行任何删除操作只输出脚本让用户自己运行。 需求 1. 统计 C:\Users\某个用户名\AppData 下所有一级子目录的大小。 2. 继续进入体积超过 2GB 的子目录统计它的二级子目录大小。 3. 不要漏掉隐藏目录。 4. 结果按体积从高到低排列输出单位使用 GB。 5. 把脚本保存到 C:\Temp\appdata_size.ps1并额外输出一份 Markdown 报告。 注意 - 必须使用 -Force 参数。 - 遇到无权限目录时跳过不要中断。 - 脚本只做统计禁止出现 Remove-Item、del、rm 等删除命令。这里有几个要点。第一个是“只输出脚本让用户自己运行”这句话能让它把操作权交还给你避免直接在终端里执行删除。第二个是“不要中断”缓存目录里经常有正在运行程序的锁文件读取失败不能打断整体统计。第三个是禁止删除命令要写明白别留给模型自由发挥。Codex 生成的脚本我一般不会直接跑而是先读一遍看它“有没有碰配置目录、有没有把路径写错、有没有加无关参数”。确认没问题以后再让脚本生成报告。它的核心价值是把重复劳动压缩掉而不是替你承担判断责任。3. 逐层定位 87.81GBTemp、缓存、日志一个都不放过3.1 第一步先看 AppData\Local\Temp我那次扫描结果里AppData\Local\Temp排名第一这点其实不意外。几乎每个软件安装包解压、系统更新暂存、开发工具编译中间文件都会往这里丢东西。网上流传的“Temp 可以随便删”不完全对更准确的说法是Temp 目录里正在被占用的文件不能删其余可以安全清理。我当时先单独看 Temp 的体积$tempPath $env:LOCALAPPDATA \Temp $tempSize (Get-ChildItem -LiteralPath $tempPath -Recurse -File -Force -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum).Sum [PSCustomObject]{ 路径 $tempPath; 体积GB [math]::Round($tempSize / 1GB, 3) }输出显示 Temp 里躺着 23.5GB 的文件。点进去看了一下有几类东西占大头一类是*_unsaved3这种编辑器临时文件另一类是安装包解压出来的*.cab、*.msi还有一类是某些下载器半途而废留下的.part文件。这里要提醒一下Temp目录下某些带版本号的文件夹比如ArduinoIDE-unsaved*或者Codex-*之类名字看着专业其实只是某个软件的临时产物大多数情况下删除不造成影响。但不要删除Temp根目录本身最多清空里面的内容因为系统很多程序仍在引用这个路径。3.2 接着是各类开发缓存uv、pip、npm顺着体积排序往下看第二梯队被开发工具缓存包揽了。AppData\Local\uv占了不少pip\cache也是老熟人npm-cache同样没让人失望。这三兄弟的特点完全一致包管理器运行时会下载依赖包并缓存下次安装相同版本时就不需要重新下载。实际上很多依赖包装完一次就不会再碰缓存留在那里纯粹是心理安慰。对这类缓存不需要手动去翻文件直接用包管理器自带的清理命令最干净。我当时的建议顺序是优先清 pip再清 npm再清 uv因为不同工具的缓存机制差异很大pip cache purge npm cache clean --force uv cache clean关于npm-cache多说一句不要看到Cache这个词就直接Remove-Item整个目录因为 npm 的缓存目录里还有一个_cacache索引粗暴删除后有些旧项目再安装依赖时可能会因缓存索引不一致而报错。用官方命令清理它会连索引一起重建干净又省心。有些读者在热搜里看到过一个路径类似C:\Users\Administrator\AppData\Local\Temp\.arduinoide-unsaved202695-10792-10。这种其实是Temp内部的子目录我当时的处理方式是直接放进Temp整体的清理名单里没有单独纠结。它的使命就是存临时文件要是哪天 IDE 闪退重启旧临时文件残留很正常删掉通常没有后遗症。3.3 别忘了 Roaming 下的全局包与日志Local目录处理完之后我让 Codex 把Roaming也扫了一遍。和很多人想象的不同Roaming有时候比Local更吓人。什么 npm 全局包的旧版本、Electron 缓存、一些编辑器的崩溃日志都会往这里堆。以npm为例如果你曾经用npm install -g装过全局工具它们会被放在Roaming\npm\node_modules下。旧版本的anthropic-*、babel/*之类的包残留单个只有几十 MB但累计起来就是几个 GB。清理这种目录之前建议先用npm ls -g --depth0确认哪些包还在用或者干脆直接执行npm rebuild整理。千万别把整个node_modules一刀切那等于把自己所有全局命令行工具全卸了。日志文件也是我重点排查的项目。许多软件会把日志写到Roaming\SoftwareName\logs系统日志则可能出现在Local\Temp或者Roaming\Microsoft\Windows下。日志文件的特征是单文件小但数量巨大几千个小文件叠起来也有几个 GB。我的筛选方法是按文件数量排序而不是按单文件大小Get-ChildItem -LiteralPath $env:APPDATA -Recurse -File -Force -ErrorAction SilentlyContinue | Group-Object { $_.DirectoryName } | Sort-Object Count -Descending | Select-Object -First 10 | Format-Table Count, Name -AutoSize输出里如果某个目录下有几千个.log那它的体积通常也很可观而且基本可以放心清理。3.4 盘点表不同类型目录的安全等级扫完几轮之后我习惯把结果汇总成一张表方便看着决定优先级。虚拟一份当时的结果供参考路径体积清理优先级清理方式风险等级Local\Temp23.5 GB高清空内容低Local\pip\Cache9.8 GB高pip cache purge极低Local\npm-cache7.6 GB高npm cache clean --force极低Local\uv\cache6.9 GB高uv cache clean极低Local\NVIDIA\DXCache5.2 GB中直接删内容低Roaming\npm\node_modules4.1 GB中npm rebuild后处理中Local\Microsoft\Windows\INetCache3.3 GB中系统磁盘清理低Roaming\*\logs2.6 GB中删 .log 文件低其余配置目录24.6 GB低不处理高表格里的“其余配置目录”其实占了总空间的三分之一但基本没动。它们大多是微信、浏览器、输入法、办公软件的用户数据删了有一个算一个全是坑。4. 开始动手清理哪些能删、哪些必须用命令处理4.1 逐个执行清理命令别一把梭确认完清单终于到了动手环节。我当时的执行顺序是从风险最低的缓存开始每清完一个就重新看一次剩余空间确保每一步都不失控。Temp 目录用命令清空Remove-Item -LiteralPath $env:LOCALAPPDATA\Temp\* -Recurse -Force -ErrorAction SilentlyContinue这条命令的意思是删除 Temp 下所有内容但忽略正在被占用的文件。这里重点排查只要进程仍然打开某个文件Windows 就不会允许删除它加了 -ErrorAction SilentlyContinue 也只是跳过错误不会强制占用中的文件。所以跑完后 Temp 目录不会变成 0 KB这是正常现象别以为命令没生效。DXCache 属于显卡驱动生成的着色器缓存删掉不影响系统只会在下次游戏或图形软件启动时重建。清理方式Remove-Item -LiteralPath $env:LOCALAPPDATA\NVIDIA\DXCache\* -Recurse -Force -ErrorAction SilentlyContinueNVIDIA 并不只是一个目录AMD 的GLCache、Intel 的ShaderCache位置不同但处理逻辑一样删除子目录内容即可。这类缓存的体积随着你运行的大型游戏数量增长定期清一清完全合理。4.2 打开系统自带的“存储感知”和磁盘清理第三方“清理大师”我从来不用Windows 自带的两把刀子反而靠得住。第一把是“存储感知”在“设置 → 系统 → 存储”里打开它会定期自动删除临时文件和回收站内容。第二把是“磁盘清理”它是跟着系统走的老牌工具外部不敢说但删除旧的 Windows 更新备份这事只敢交给它在“此电脑”的 C 盘上右键选择“属性”点击“磁盘清理”。等它扫描完第一轮再点击“清理系统文件”。注意勾选“Windows 更新清理”和“设备驱动程序包”这两项经常能扫出好几 GB。确认无误后点击确定等待执行完成。别看这一步简单很多人不知道要再点一次“清理系统文件”。不加这一步清理工具和你平时看到的界面是一样的永远清不出旧更新文件加完这一步扫描结果完全是两个世界。4.3 别删的目录我单独拉一张清单网上很多“清理教程”动不动就让你删某个路径我这次清理完毕后把实际动过刀和坚决不动的目录汇总成一张“避坑清单”可以定期清理千万不能删AppData\Local\Temp整个AppData目录包管理器缓存pip/npm/uvAppData\Roaming下的软件配置显卡着色器缓存AppData\Local\Google浏览器个人配置软件运行日志AppData\Local\Microsoft下的账号相关数据系统临时更新文件各种软件安装目录里的数据文件避坑的原则非常简单凡是“可再生”的删凡是“需要重新配置或重新下载”的慎重凡是“只有一份”的坚决不删。4.4 把缓存默认路径迁移出系统盘清理完只是第一步如果下一次重新安装依赖包缓存又会被写回这些位置几个月后历史重演。我当时顺手做了一件事把部分开发工具的缓存目录迁到数据盘。以 uv 为例它支持通过环境变量UV_CACHE_DIR修改缓存路径。在“系统属性 → 环境变量”里新建一个用户变量变量名: UV_CACHE_DIR 变量值: D:\DevCache\uv然后重新打开终端执行uv cache dir确认新路径生效。以后 uv 下载的包缓存就会落到 D 盘C 盘不再被动增长。npm 全局包位置也可以用npm config set cache D:\DevCache\npm-cache修改pip 则通过配置pip config set global.cache-dir D:\DevCache\pip-cache调整。这套思路对任何“会反复下载大量依赖”的工具都适用本质上就是把本应放在系统盘的重型缓存挪走让 C 盘只承担系统文件和应用本身。5. 我踩过的坑常见问题与排查实录5.1 清理完了空间没降多少是哪里漏了最常见的新手困惑明明按教程清了 Temp、清了缓存、清了一堆东西结果 C 盘空间只少了几个 GB。这时候我会提醒你去看三样“隐藏大佬”休眠文件hiberfil.sys、虚拟内存页面文件pagefile.sys、以及“系统还原”所产生的还原点。hiberfil.sys的默认大小是物理内存的 40%~80%。一台 32GB 内存的电脑休眠文件可能轻松占掉十几 GB。如果你平时根本不用“休眠”注意休眠不等于睡眠可以关闭休眠来释放空间。在管理员权限的终端里执行powercfg /h off执行之后系统会删除hiberfil.sys。但要注意这个操作会让“开始菜单 → 电源 → 休眠”选项消失后续如果需要休眠再用powercfg /h on恢复。另外页面文件也别乱删它被系统用于内存交换除非你确定自己内存足够否则由它去。5.2 删到一半提示文件被占用怎么办这是所有清理过程里最常弹窗的阶段。遇到“无法删除文件已在系统中打开”时第一反应不要是去找什么“强制删除工具”而是先判断这个文件属于哪个进程。按文件路径搜索进程比较好用的是Get-Process | Where-Object { $_.Path -notlike } | Select-Object ProcessName, Path如果缓存目录里的文件被某个程序锁定最省事的办法是退出那个程序后再删。比如 TypeScript 编译器的临时文件被编辑器锁定那就把编辑器关掉再清。如果连进程都查不到是谁占用就跳过这个文件不要为了一两个残留文件跟系统较劲。5.3 C 盘满了之后开不了机甚至闪退C 盘剩余空间低到一定程度系统连创建临时文件都做不到开机过程自然可能卡死运行软件也会出现各种莫名其妙的闪退。最稳妥的救援方法是进安全模式清理。如果还能看到登录界面在登录页按住 Shift 键的同时点击“电源 → 重启”进入“选择一个选项”菜单选择“疑难解答 → 高级选项 → 启动设置 → 重启”然后按 4 进入安全模式。安全模式下大部分第三方软件不会启动Temp 目录里的占用文件会少很多这时候再执行清理命令成功的几率会明显提升。如果连登录界面都到不了那就只能靠启动 U 盘或 PE 环境了。这个操作对新手来说有点复杂但只要保住数据牺牲点时间是值得的。我建议平时就在抽屉里放一个“救机 U 盘”而不是等到黑屏那天到处找工具。5.4 恢复分区在 C 盘后面怎么扩展容量很多人清理完发现空间还是不够用想把D盘空间合并给C盘结果分区软件提示恢复分区挡在中间。这事别硬来。恢复分区的作用是提供系统重置入口直接删掉它会让“重置此电脑”和部分恢复功能失效。如果确实需要扩展 C 盘比较保守的做法是先用“设置 → 系统 → 恢复 → 高级启动”确认系统恢复功能正常然后用自己的方式把恢复环境备份到外部媒体再用磁盘管理把恢复分区删除并扩展 C 盘。这类操作涉及分区表变更一旦断电或中断可能损坏整个磁盘普通用户我不建议为了几个 GB 的空间去动它。更省心的替代方案是保持分区结构不动把大型应用和缓存迁走让 C 盘保持 20GB 以上的余地效果不比扩容差。6. 我的额外体会让清理从“事故”变成“日常”6.1 给 Codex 建一个周期性的“体积日报”那次清理结束大约两周后我发现 C 盘的可用空间又开始缓慢下降。为了不再等到爆红才处理我给 Codex 设定了一个定时任务思路每周写一个脚本自动扫描常用缓存目录的体积变化并输出一份简短的报告。这个任务不用写得太复杂核心就是把上文那些统计命令组合起来。重点是路径要固定比如 Temp、pip、npm、uv、DXCache、浏览器缓存每个目录记录体积、文件数和上一条报告里的差异值。如果某个缓存目录体积在一周内增长超过 2GB就值得去看一眼里面到底是什么。执行频率我用的是“每周一次”。每天跑太频繁没有意义毕竟缓存增长需要时间一个月跑一次又太长等发现涨到几十 GB 后再处理就很被动。6.2 缓存迁移之后真正的长期习惯如果只让我说一条最实用的建议那就是别等系统红了才想起来清把所有能搬走的缓存路径在第一次装上开发工具时就迁到非系统盘。这事听起来很反直觉——毕竟缓存默认都在用户目录改环境变量好像多此一举。但请你算一笔账一个开发环境装上 Node、Python、Rust、Go、前端工程缓存目录加起来轻松超过 30GB你把这些全部留给 C 盘就等于给自己埋了一颗定时炸弹。我现在的习惯是在重装系统或者换新电脑之后前两小时就花在处理环境变量上而不是等硬盘满了再去跟系统搏斗。操作不复杂唯一需要记住的就是“路径要提前建好工具要重启一次才生效”。6.3 UWF 这类“C 盘保护”方案先别急着用热搜词里有人提到uwfmgr它是 Windows 统一写入筛选器可以把 C 盘做成“每次重启还原”的模式。听起来很美所有删除垃圾的操作都免了但它有个核心限制用户的一切写入也被丢弃相当于你每开一次机都回到上一次启动的状态。装个软件、改个配置、保存个文件重启后全部消失这明显不适合普通办公和开发场景。如果你没有特殊需要我还是建议用“定期清理 缓存迁移”这套传统打法而不是过度依赖这类底层保护工具。回到最初那个问题AppData 占了 87.81GB要不要删我的答案在文章开头就给过了现在再复述一遍要清但只清可再生的部分保留配置和存档。用 Codex 做体积分析、用 PowerShell 执行具体清理、用环境变量转移缓存路径这三板斧叠加C 盘没有再红过的迹象。大家下次看到 AppData 变大可以先深呼吸开个终端让数据替你把话说清楚。
RELATED READING

延伸阅读

更多一线实战笔记与深度复盘,助您持续精进