C盘爆红别乱删！用Codex排查AppData隐藏空间

1. 从一次C盘告急说起：为什么“删文件”是最差的选择

那天下午，我正在赶一个跨平台项目的构建包，IDE突然弹窗提示磁盘空间不足，紧接着整个系统开始卡顿，连保存代码都要等上好几秒。切到资源管理器一看，C盘那条进度条已经红得发紫，剩余空间不到3GB。按照大多数人的第一反应，我打开了“下载”文件夹和“桌面”，把能删的安装包、旧文档、截图一股脑清掉，腾出来大概8GB。结果重启之后，C盘又红了。

这个场景我相信你大概率也遇到过。很多人处理C盘爆红的方式就是“哪里大删哪里”，盯着用户目录下的几个显眼文件夹下手，删完发现治标不治本，过两天空间又被吃回去。问题的关键在于：你看到的“大文件”往往不是真正的元凶，真正的空间黑洞藏在那些默认隐藏、名字又看不懂的系统级目录里。其中嫌疑最大的，就是AppData。

AppData是 Windows 用户配置目录下的一个隐藏文件夹，全路径通常是C:\Users\你的用户名\AppData。它下面分三个子目录：Roaming、Local、LocalLow。几乎所有你安装的软件都会往这里写数据——缓存、日志、配置、模型文件、临时数据库，全都塞在这。它不像“下载”文件夹那样一目了然，也不像“文档”那样有明确的归属感，所以绝大多数人根本不会主动去翻它。

我这次的情况是：用 Codex 辅助排查之后，发现AppData一个目录就占了87.81GB。注意，是单个目录，不是整个C盘。这个数字意味着什么？意味着一台256GB固态的笔记本，光这一个隐藏文件夹就吃掉了超过三分之一的容量。更关键的是，这87.81GB里，真正“必须保留”的部分可能连10GB都不到，剩下的全是各种软件日积月累留下的缓存和冗余数据。

所以这篇内容我想聊的不是“怎么删文件”，而是怎么用工具把空间去向查清楚，再决定删什么、留什么。我会把整个排查链路、Codex 在其中的作用、AppData 里各个子目录的取舍逻辑，以及我实测下来最稳的清理策略，完整地拆开讲。适合两类人看：一类是C盘已经红了、急着找原因的；另一类是C盘还没红、但想提前建立一套“空间管理习惯”的。不管你是开发、设计还是普通办公用户，这套方法都能直接抄。

2. 为什么肉眼排查一定会漏：AppData 的空间分布逻辑

2.1 隐藏属性带来的“视觉盲区”

Windows 默认不显示隐藏文件夹，而AppData恰好带隐藏属性。这就导致一个很尴尬的局面：你在资源管理器里一层层点进去，看到的文件夹大小加起来，跟C盘实际占用对不上。差的那些去哪了？就藏在隐藏目录里。

我做过一个对比实验。在一台用了两年的办公机上，我先把资源管理器设置成“显示隐藏文件”，然后逐层统计用户目录下各文件夹的大小。结果是这样的：

可以看到，光AppData一个目录，就比所有可见用户文件夹加起来还要大好几倍。如果你只盯着可见目录删，等于在游泳池里舀水，而真正的大象站在旁边你根本没看见。

2.2 AppData 三个子目录的分工差异

AppData下面那三个子目录，名字看着像随便起的，其实各有明确分工，清理策略也完全不同。

Roaming的设计初衷是“跟着用户走”。在域环境或者多设备同步的场景下，这个目录里的配置会随账号漫游。所以它里面装的多是软件的配置文件、用户偏好设置、小型数据库。比如你某个编辑器的主题配置、某个聊天工具的账号信息，大概率在这里。这个目录一般不会特别大，但也不能乱删，删了软件就得重新配置。

Local是真正的“重灾区”。它存放的是只属于当前这台机器的数据，包括缓存、临时文件、日志、模型权重、索引库等等。绝大多数软件的“体积膨胀”都发生在这里。我这次查出来的87.81GB，有超过80GB集中在Local下面。原因很简单：软件厂商默认把最占空间的东西往这儿扔，因为这里不需要同步，删了也不影响账号数据。

LocalLow相对小众，主要给一些低完整性级别的程序用，比如浏览器插件、部分游戏。它通常不会太大，但偶尔也会有意外，比如某些游戏会把存档或者资源包放这里。

理解了这三个目录的分工，你就能建立一个基本判断：清理的重点在Local，Roaming要谨慎，LocalLow顺手看看就行。但具体到哪个软件、哪个子文件夹，光靠名字是猜不出来的，必须借助工具把大小量化出来。

2.3 软件缓存策略的“原罪”

为什么AppData会膨胀到几十GB？这跟现代软件的缓存策略有直接关系。举几个我实测中遇到的典型情况：

• 某代码编辑器会把每次打开项目的索引缓存全部保留，一个中型项目索引动辄几百MB，开过几十个项目之后，Local下对应的缓存目录就能到十几GB。
• 某通讯软件会把接收过的所有图片、视频、文件在本地留一份副本，哪怕你在聊天窗口里已经“清理”过，本地缓存依然在。
• 某浏览器会把每个站点的缓存、Service Worker 数据、离线资源分开存储，用久了轻松上GB。
• 某AI辅助工具会把模型文件、会话历史、临时生成的中间产物全部落在Local下，而且默认不自动清理。

这些行为单独看都“合理”，但叠加在一起，就是C盘爆红的直接原因。更麻烦的是，很多软件在卸载时并不会清空这些缓存目录，导致你卸载了软件，空间却没回来。

3. Codex 在排查中到底做了什么：从“猜”到“量化”

3.1 为什么不用资源管理器的“大小”列

有人可能会问：资源管理器不是有“大小”列吗，按大小排序不就行了？理论上可以，但实际用起来有几个硬伤。

第一，资源管理器统计文件夹大小时，遇到大量小文件会非常慢，一个几万文件的缓存目录能卡到你怀疑人生。第二，它不会递归统计所有子目录的汇总大小，你只能一层层点进去看。第三，隐藏目录和系统保护目录它经常直接跳过，统计结果不完整。第四，它没法按“文件类型”或者“修改时间”做交叉筛选，你没法快速判断哪些是“陈年垃圾”。

所以我的做法是：用命令行工具做快速扫描，用 Codex 做结果解读和清理脚本生成。这两者配合起来，效率比纯手工翻目录高一个数量级。

3.2 用 PowerShell 做第一轮体量扫描

第一步不需要任何第三方工具，Windows 自带的 PowerShell 就能干。打开 PowerShell，不需要管理员权限，直接跑下面这段：

$target = "$env:USERPROFILE\AppData" Get-ChildItem -Path $target -Directory -Recurse -ErrorAction SilentlyContinue | ForEach-Object { $size = (Get-ChildItem -Path $_.FullName -Recurse -File -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum).Sum [PSCustomObject]@{ Folder = $_.FullName.Replace($target, "AppData") SizeGB = [math]::Round($size / 1GB, 2) } } | Sort-Object SizeGB -Descending | Select-Object -First 30 | Format-Table -AutoSize

这段脚本的逻辑很直白：递归遍历AppData下所有子目录，对每个目录再递归统计文件总大小，最后按GB排序取前30名。-ErrorAction SilentlyContinue是为了跳过那些权限不足或者路径过长的目录，避免报错中断。

跑完之后，你会得到一张表，清楚地列出AppData下最占空间的30个目录。我那次跑出来的前几名大概是这样的（数值做了模糊处理）：

到这一步，空间去向已经基本清楚了。但“清楚”不等于“知道怎么处理”，因为你还得判断：哪些能删、哪些不能删、删了会有什么后果。这就是 Codex 发挥作用的地方。

3.3 让 Codex 解读扫描结果并生成清理方案

我把上面那张表直接贴给 Codex，然后问了一个很具体的问题：“这些目录里，哪些是可以安全清理的缓存，哪些是必须保留的用户数据？请按风险等级分类，并给出对应的清理命令。”

Codex 的回复质量取决于你怎么问。我的经验是，不要问“怎么清理C盘”这种大而空的问题，要把具体的目录路径、软件类型、你的使用习惯一起给它。比如我会补充：“某AI工具的models目录我还在用，不能删；某编辑器我最近三个月没打开过；某通讯软件的聊天记录我需要保留。”

基于这些约束，Codex 给出的分类大致是这样的：

• 低风险，可直接清理：各类Cache、Temp、Code Cache、GPUCache、logs目录。这些是纯缓存，删了软件会重新生成，最多首次启动慢一点。
• 中风险，需确认后清理：FileStorage、Downloads（在AppData里的）、Service Worker缓存。这些可能包含你需要的文件，建议先备份或者确认软件内有云端副本。
• 高风险，不建议手动删：Roaming下的配置文件、Local下的数据库文件（.db、.sqlite）、授权信息、模型权重（如果你还要用）。

这个分类不是 Codex 凭空编的，而是基于它对常见软件目录结构的理解。我实测下来，准确率相当高，至少比我凭名字猜要靠谱得多。

3.4 生成可复用的清理脚本

分类清楚之后，Codex 帮我生成了一段清理脚本。这段脚本的核心思路是：只删明确安全的缓存目录，删之前先打印出来让你确认，删的时候跳过正在被占用的文件。

$safePatterns = @( "*\Cache\*", "*\Code Cache\*", "*\GPUCache\*", "*\Temp\*", "*\logs\*", "*\Crashpad\*" ) $base = "$env:USERPROFILE\AppData\Local" $totalFreed = 0 Get-ChildItem -Path $base -Directory -ErrorAction SilentlyContinue | ForEach-Object { $appDir = $_.FullName foreach ($pattern in $safePatterns) { $candidates = Get-ChildItem -Path $appDir -Filter ($pattern -replace '^\*\\','') -Recurse -Directory -ErrorAction SilentlyContinue foreach ($dir in $candidates) { $size = (Get-ChildItem -Path $dir.FullName -Recurse -File -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum).Sum Write-Host "将清理: $($dir.FullName) 大小: $([math]::Round($size/1MB,1))MB" Remove-Item -Path $dir.FullName -Recurse -Force -ErrorAction SilentlyContinue $totalFreed += $size } } } Write-Host "本次共释放: $([math]::Round($totalFreed/1GB,2))GB"

注意：这段脚本会直接执行删除操作。建议你先去掉Remove-Item那一行，只跑打印部分，确认清单没问题之后再执行删除。另外，正在运行的软件对应的缓存目录可能删不掉，这是正常的，跳过即可。

我用这段脚本跑了一遍，释放了大约22GB。剩下的空间大头是那个AI工具的模型文件（31.2GB）和通讯软件的聊天文件（11.5GB），这两个我选择保留，但通过软件自带的设置把存储路径迁移到了D盘。

4. AppData 里哪些能动、哪些碰不得：一份实测取舍清单

4.1 可以放心删的目录特征

经过这次排查和后续几次清理，我总结出一个简单的判断标准：如果目录名里带 Cache、Temp、Log、Crash、GPUCache、Code Cache、Shader Cache 这些词，基本都可以删。这些目录的作用就是“加速下次访问”，删了之后软件会重新生成，代价只是第一次打开稍微慢一点。

具体到常见软件，我实测可以安全清理的有：

• 浏览器的Cache、Code Cache、GPUCache、Service Worker\CacheStorage
• 代码编辑器的CachedData、CachedExtensions、logs
• 通讯软件的Image、Video、FileStorage里的过期文件（建议在软件内清理，不要手动删）
• 各类Temp目录，包括Local\Temp本身
• 崩溃报告目录，如Crashpad、CrashReports

这些目录加起来，通常能占到AppData总空间的30%到50%。也就是说，如果你AppData有80GB，光清理这些就能释放25GB到40GB。

4.2 需要谨慎对待的目录

有些目录名字看起来像缓存，但实际上可能包含你的个人数据，删之前一定要确认。

Roaming下的配置文件首当其冲。比如某笔记软件的本地数据库、某密码管理器的加密库、某开发工具的授权文件，这些如果删了，轻则重新登录，重则数据丢失。我的做法是：Roaming下的东西，除非明确知道是缓存，否则一律不动。

Local下的FileStorage、Downloads、Documents这类目录也要小心。通讯软件的FileStorage里可能存着你接收过的所有文件，虽然软件里能看到，但手动删了之后，聊天记录里的文件链接就会失效。这类目录最好通过软件自带的“存储管理”功能来清理，而不是直接删文件夹。

还有一个容易被忽略的是Local\Packages，这是UWP应用的数据目录。里面的LocalCache、TempState可以清，但LocalState通常包含应用的核心数据，不要碰。

4.3 绝对不能手动删的核心数据

有几类东西，我建议你碰都不要碰：

• 数据库文件：.db、.sqlite、.mdb结尾的文件，很多软件的本地数据都存这里，删了等于清空。
• 授权与凭证：token、credential、license、auth相关的文件或目录。
• 模型权重：如果你在用本地AI工具，models目录下的文件动辄几十GB，但删了就得重新下载，而且很多模型下载很麻烦。
• 正在使用的软件的主目录：比如你天天用的编辑器、浏览器，它们的User Data根目录不要整个删，只能删里面的缓存子目录。

我踩过一次坑：早期为了省空间，把某编辑器的整个User Data目录删了，结果所有插件配置、快捷键、主题全部重置，花了一个多小时才恢复。从那以后我就定了个规矩：只删明确标记为缓存的子目录，绝不删父级目录。

4.4 用“迁移”代替“删除”的思路

有些目录你既不想删，又不想让它占C盘，怎么办？答案是迁移。Windows 支持用目录联接（Junction）把某个目录映射到其他盘，软件依然以为自己在读写原路径，实际数据存在D盘。

操作方式是用管理员权限打开命令提示符，执行：

robocopy "C:\Users\你的用户名\AppData\Local\某软件" "D:\AppDataMigration\某软件" /E /MOVE mklink /J "C:\Users\你的用户名\AppData\Local\某软件" "D:\AppDataMigration\某软件"

第一行把数据搬到D盘，第二行在原位置创建一个联接点。这样软件无感知，C盘空间却释放了。我用这个方法把那个31.2GB的模型目录迁到了D盘，C盘瞬间多出30GB。

提示：迁移之前一定要先关闭对应软件，否则文件被占用会导致复制不完整。迁移完成后打开软件验证一下功能是否正常，确认无误再清理D盘上的临时副本。

5. 一套可复用的C盘空间管理流程

5.1 定期扫描，建立基线

清理不是一劳永逸的事。软件每天都在产生新缓存，所以我的做法是每个月跑一次扫描脚本，记录AppData的总大小和前十大目录。这样你就能看出哪些软件在“偷偷膨胀”。

比如我连续记录了三个月的数据，发现某通讯软件的FileStorage每月增长约2GB，某浏览器的Cache每月增长约1.5GB。有了这个基线，我就知道该重点盯谁，而不是每次盲目全盘扫描。

5.2 分级清理，先软后硬

清理顺序我建议这样排：

1. 先用软件自带清理功能：浏览器、通讯软件、编辑器基本都有“清除缓存”选项，优先用官方的，最安全。
2. 再用脚本清理通用缓存目录：就是前面那段 PowerShell 脚本，处理那些软件不提供清理入口的缓存。
3. 最后考虑迁移：对于必须保留但又太大的目录，用目录联接迁到其他盘。
4. 手动删除作为最后手段：只有在明确知道目录用途的情况下才手动删。

这个顺序的核心逻辑是：能自动的不手动，能迁移的不删除，能保留的不冒险。

5.3 把Temp目录也纳入管理

Local\Temp是个特殊存在，很多软件安装、解压、运行时都会往这里写临时文件，但用完不一定清理。我实测一台用了半年的机器，Temp目录能积累到6GB以上。

清理Temp有个小技巧：不要直接全选删除，因为有些文件正在被系统或软件占用。正确做法是重启之后立刻清理，这时候大部分临时文件已经释放。或者用“磁盘清理”工具里的“临时文件”选项，它会自动跳过正在使用的文件。

5.4 给C盘留出安全余量

最后说一个观念上的问题。很多人觉得“C盘还有10GB就够用”，但实际上Windows在空间不足时会触发各种异常行为：更新失败、虚拟内存不足、软件崩溃。我的经验是，C盘至少保留15%到20%的可用空间。以256GB的盘为例，至少要留40GB以上。

如果你经常遇到C盘爆红，与其每次临时抱佛脚，不如把上面这套流程固化下来：每月扫描一次，每季度深度清理一次，大目录及时迁移。这样C盘就能长期保持健康状态。

我在实际使用中发现，真正难的不是清理本身，而是判断什么该留什么该删。Codex 在这件事上的价值，不是替你执行删除，而是帮你把“看不懂的目录”翻译成“能决策的信息”。有了这个翻译过程，你才敢下手，也才知道下手之后会有什么后果。这套方法我用了大半年，C盘再没红过，希望对你也有用。