C盘报警那天我印象特别深，剩余空间只剩几GB，微信发个文件都提示磁盘不足。打开资源管理器一看，C:\Users\我的用户名\AppData这个目录占了 87.81GB，占了整个C盘将近三分之一的容量。换作以前，我可能已经冲进各种文件夹开始手动删了，但这次我没动。以前乱删 C 盘吃过太多亏：软件打不开、配置全丢、账号要重新登录、甚至系统都出现过不稳定。所以这次我换个玩法，让 AI 编码助手 Codex 帮我先摸清这 87.81GB 到底是怎么堆起来的，再决定哪些该删、哪些绝对不能碰。整个过程下来，没有误删任何重要数据，最后实际释放了将近 30GB，而且后续一个多月 C 盘都没再爆红。这篇就完整复盘一下我的思路、操作和踩过的坑，适合那些 C 盘常年吃紧、又不敢乱删文件的人参考。
1. C盘爆红时最忌讳的做法，和 AppData 的基础认知
1.1 乱删 C 盘的三大代价
很多人 C 盘一红就慌，第一反应是“找到大文件夹删掉就完事了”。这个思路本身没错，但执行方式如果太粗糙，代价是很直接的。
第一个代价是应用崩溃。某些软件会把运行所需的关键组件放在 AppData 下的某个固定路径里，表面看那些文件没什么用，但软件启动时如果找不到，轻则闪退重则直接无法运行。我以前就“清理”过一个目录，结果某个常用工具直接罢工，修复花了一个下午。
第二个代价是登录状态和配置丢失。不少应用的登录令牌、会话缓存、用户配置都存在 AppData 下。删掉这些目录，等于强制所有软件退出登录，配置重置回初始状态。如果里面还存着没同步的草稿、自定义快捷键、窗口布局，全没了。
第三个代价更隐蔽：白删。有些目录看起来巨大无比，你费了半小时找到主文件夹，右键删除确认，结果空间根本没释放多少。原因很多，下面会详细讲，但核心问题在于：不看结构就下手，大概率做无用功。
提示：C 盘爆红后最应该做的第一件事，不是删，是搞清楚到底什么在占空间。
1.2 AppData 究竟是存什么的
AppData 是 Windows 下用户目录中的隐藏文件夹之一，专门用来存放各类应用程序的数据。它有三个子目录：Local、LocalLow、Roaming。三者差别很大，不理解这一点，后面所有操作都是在盲人摸象。
| 子目录 | 存储内容 | 是否随用户漫游 | 容易变大的典型场景 |
|---|---|---|---|
| Local | 本机专属数据、缓存、临时文件 | 否 | 浏览器缓存、开发工具缓存、崩溃转储、下载缓存 |
| LocalLow | 低完整性级别的应用数据 | 否 | 某些浏览器插件、兼容模式下运行的辅助组件 |
| Roaming | 需要跟随用户迁移的应用数据 | 是 | 聊天记录、用户配置、同步数据 |
简单说：Roaming 里大多是“正经数据”，哪怕它体积很大，也大概率属于不可随意删除的类型。Local 里既有正经数据，也有大量可以随时重新生成的缓存，是清理时的重点关注对象。LocalLow 通常体量不大，但偶尔也能看到一些浏览器或插件的缓存堆在那里。
AppData 之所以容易爆炸，核心原因是很多软件默认把缓存和临时文件往这里塞，而且只写不删。比如说开发工具，每次拉取依赖包、编译生成中间产物，都会往 Local 下的缓存目录里丢文件，日积月累几十GB不稀奇。浏览器也一样，网页缓存、视频流缓存，常年不清能累积出一片天地。
2. 我为什么用 Codex 来排查，以及具体怎么让它干活
2.1 传统磁盘分析工具和 AI 辅助的本质区别
以前排查 C 盘，大家习惯用各类磁盘占用分析器，扫描完会得到一个大饼图，告诉你哪个文件夹大。这个方案有一个天生缺陷：它只告诉你哪里大，不告诉你能不能删。
你可能知道某文件夹占了 20GB，但完全不知道它是应用的核心数据还是可再生缓存。真要分析每个目录的用途，还得一个个搜索、查资料、判断风险，工作量一点不小。
这次换 Codex 来干，核心是想解决三件事：目录大小统计、目录用途识别、可删性判断。前一件传统工具也能做，但后两件是 AI 的强项。我可以直接问它“这个目录是干什么的，删掉会不会有风险”，它会基于路径特征、文件类型、常规软件行为给出判断，这个过程比我自己逐个文件夹去查快得多。
2.2 让 Codex 生成目录大小统计脚本
我没让 Codex 去扫描文件，而是让它生成一个统计脚本，用代码的方式去遍历目录和计算大小。这里的关键是提示词要写清楚需求，不然出来的脚本可能不符合场景。
我当时给的提示大概是这样的：
请帮我写一个 PowerShell 脚本，实现以下功能： 1. 遍历 C:\Users\我的用户名\AppData 下的所有子目录，深度为2级。 2. 统计每个目录的总大小，包括里面的所有文件和子目录。 3. 按总大小从大到小排序，输出目录路径和大小（GB，保留两位小数）。 4. 如果目录遇到无法访问的路径，跳过继续，不要中断。 5. 输出结果先显示每个一级子目录的总大小，再显示一级子目录下最大的10个二级子目录。Codex 返回的脚本核心逻辑并不复杂，大致长这样：
$root = "C:\Users\我的用户名\AppData" $levels = Get-ChildItem -Path $root -Directory -ErrorAction SilentlyContinue foreach ($level in $levels) { $size = (Get-ChildItem -Path $level.FullName -Recurse -File -Force -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum).Sum $sizeGB = [math]::Round($size / 1GB, 2) $subDirs = Get-ChildItem -Path $level.FullName -Directory -ErrorAction SilentlyContinue $topSub = $subDirs | ForEach-Object { $subSize = (Get-ChildItem -Path $_.FullName -Recurse -File -Force -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum).Sum [PSCustomObject]@{ 路径 = $_.FullName 大小GB = [math]::Round($subSize / 1GB, 2) } } | Sort-Object 大小GB -Descending | Select-Object -First 10 Write-Host "===== $($level.Name) 总大小: $sizeGB GB =====" $topSub | Format-Table -AutoSize }脚本效果很直接，但它有一个性能隐患：用 Get-ChildItem 递归遍历海量文件时会比较慢，87GB 的目录下文件数量可能几十万个，跑完全程需要点耐心。这在首轮分析里完全可以接受，一次性投入换一个全貌，值。
2.3 首轮扫描结果给我划清了主战场
脚本运行时能看到进度，但没有实时百分比显示，只能等。整个扫描过程大约持续了几分钟，输出结果直接把问题分层了：
===== Local 总大小: 62.15 GB ===== 路径 大小GB C:\Users\我的用户名\AppData\Local\某开发工具\Cache 28.43 C:\Users\我的用户名\AppData\Local\某聊天工具\Data 15.72 C:\Users\我的用户名\AppData\Local\某浏览器\User Data 9.18 C:\Users\我的用户名\AppData\Local\Temp 5.21 C:\Users\我的用户名\AppData\Local\CrashDumps 2.61 C:\Users\我的用户名\AppData\Local\某地图工具\MapCache 2.86 C:\Users\我的用户名\AppData\Local\某音乐软件\Cache 1.37 ===== Roaming 总大小: 19.32 GB ===== 路径 大小GB C:\Users\我的用户名\AppData\Roaming\某聊天工具\存储文件 12.84 C:\Users\我的用户名\AppData\Roaming\某办公软件\配置 3.05 C:\Users\我的用户名\AppData\Roaming\某同步工具\数据 1.26 ===== LocalLow 总大小: 6.34 GB ===== 路径 大小GB C:\Users\我的用户名\AppData\LocalLow\某浏览器\Cache 5.46我盯着这个结果看了半天，最大的感受是：AppData 这个目录确实“藏龙卧虎”。光 Local 一级就 62.15GB，Roaming 19.32GB，LocalLow 6.34GB，合计正好 87.81GB，和之前看到的总数完全吻合。这说明整个统计过程是可靠的，可以基于这份数据往下分析。
3. 87.81GB 到底是怎么堆出来的
3.1 Local 目录下的几类大户
Local 目录里的第一名是开发工具缓存，28.43GB。这类目录体积膨胀的原因很单一：依赖包缓存。每次安装依赖、拉取模板、构建项目，工具都会把下载的内容缓存一份，下次构建时如果发现版本一致就直接用本地的，不再去网络下载。这个机制本来是为了提速，但问题是大部分缓存策略只管写入，不管清理。
第二名是聊天工具的 Data 目录，15.72GB。这个目录里既有接收过的文件、图片、视频，也有聊天记录数据库文件。它的特点是“真数据”和“缓存”混在一起，不能一刀切全删。后面细说。
第三名是浏览器数据，9.18GB。浏览器的 User Data 路径下，一般是几个大型子目录分走空间：Cache、Code Cache、GPUCache 这些属于可再生的缓存，删除后浏览器自己会重建；但 Bookmarks、History、Cookies、扩展程序数据这些属于真数据，删了就是真丢，所以操作时必须精确到子目录才能下手。
在线路上还看到几个独立的临时目录：Temp 5.21GB、CrashDumps 2.61GB。前者是各类程序运行时产生的临时文件，后者是程序崩溃时生成的转储文件。这两类在正常情况下都可以考虑整体清空，因为它们要么是自动重建的，要么是排错用完后就没价值的。
3.2 Roaming 和 LocalLow 里的数据要慎重
Roaming 总共 19.32GB，从名字就看得出来，这里面的数据设计初衷是跟随用户走的，所以大多是“值钱”的东西。18GB+ 的聊天工具存储文件尤其典型：它包含聊天记录、接收的图片视频文件等，是很多人用了很长时间才累积下来的数据资产，绝不属于“垃圾文件”。
不过 Roaming 里也有少量可清理项，比如某些办公软件的本地备份文件，历史版本里可能积压了大量你根本不会用到的旧版本副本。这类文件的辨别需要进目录里看具体子目录的名字和文件时间，不能凭目录总大小下结论。
LocalLow 的情况在扫描结果里相对简单，大头就是浏览器缓存 5.46GB。LocalLow 里的浏览器缓存和 Local 里的略有不同，它承载的是某些低权限模式下运行的组件产生的临时文件，删掉会影响体验吗，基本不会，刷新后自然重建。
3.3 判断“可删”还是“不可删”的核心原则
扫出来只是第一步，真正難的环节是判断。我让 Codex 辅助分析每个大户目录的用途和风险，它给出的判断思路和我的实操经验完全一致，归结为一条核心原则：凡是可以重新生成的数据，都可以删；凡是不可再生的数据，必须保。
可重新生成的数据有这些特征：缓存类（浏览器缓存、开发工具缓存、索引缓存）、临时类（Temp 目录、安装临时解压文件）、转储类（崩溃转储）、日志类（旧日志文件）、下载缓存类（更新包缓存）。
不可再生的数据有这些特征：配置数据库（聊天记录、邮件本地存储）、账号凭据（登录缓存、令牌）、用户自定义设置（软件偏好、插件配置）、需要手动操作才能产生的数据（图片、文档、下载的文件）。
这个原则听起来简单，但执行时非常考验人对目录类型的分辨能力。同一个目录下可能混着两类数据，比如聊天工具的 Data 目录，里面既有聊天记录的数据库文件（不可再生），又有接收文件后自动生成的缩略图缓存（可再生）。这时候看一眼目录里的文件结构再决定删除范围，是最稳的做法。
4. 清理实操：能删什么，怎么删，怎么防复发
4.1 放心删的几类目录和它们的共同特征
基于上面的原则，先圈定“放心删”的清单。首轮扫描发现的 87.81GB 里，我在 Codex 的辅助下把可以放心删除的目录整理成了一张表：
| 目录路径 | 大小（GB） | 删除风险 | 说明 |
|---|---|---|---|
| 某开发工具\Cache | 28.43 | 低 | 构建时会自动重新下载依赖 |
| Temp | 5.21 | 低 | 临时文件，删除不影响系统和应用 |
| CrashDumps | 2.61 | 低 | 崩溃转储，普通用户用不到 |
| 某浏览器\User Data\Default\Cache | 约4.80 | 低 | 自动重建，只是首次打开网页稍慢 |
| 某地图工具\MapCache | 2.86 | 低 | 再次使用时重新下载 |
| 某音乐软件\Cache | 1.37 | 低 | 重新缓冲一段即可 |
这几个目录合计大约 45GB，是清理的主力。删之前我特意确认过一点：目标目录必须处于“未使用状态”。开发工具要关掉，浏览器要关掉，音乐软件要退出，否则正在被占用的文件会删除失败，而且可能把可执行程序的文件锁住，导致清理不干净或者应用报错。
4.2 需要谨慎处理的目录，怎么保数据只删“杂质”
处理最麻烦的不是能放心删的，而是聊天工具 Data 目录这样的混合区。15.72GB 里，真正属于“垃圾”的其实是几类：接收文件后生成的缓存缩略图、图片查看器的预缓存、数据库的日志文件。聊天记录本体和已保存的图片视频必须留着。
我当时的方法是先把目录里的大文件列表拉出来，让 Codex 帮忙按扩展名分类，找出哪些属于缓存类。实际操作时我没有盲目进去删，而是先看了该目录下的子文件夹结构，把“缓存”、“thumbnail”、“tmp”、“log”这类关键字的文件夹标出来，单独统计它们的体积。确认这些文件夹确实只是缓存后，再执行删除。
| 文件类型 | 处理建议 | 原因 |
|---|---|---|
| 聊天记录数据库 | 保留 | 核心数据，删除等于丢记录 |
| 接收的图片视频原图 | 保留 | 用户主动保存的内容 |
| thumbnail 缩略图文件夹 | 可删 | 打开聊天窗口时会重新生成 |
| tmp 临时文件夹 | 可删 | 清理后不影响正常功能 |
| log 日志文件夹 | 可删 | 排错时才有用的输出文件 |
| 表情包缓存 | 可删 | 再次使用会重新加载 |
这一轮谨慎清理下来，聊天工具 Data 目录从 15.72GB 降到了大约 11.30GB，释放了 4.4GB。不多，但至少不会误伤任何聊天记录。
4.3 删除执行的关键细节
删除命令我依然选择了让 Codex 处理。它生成了一段 PowerShell 代码，核心是用 Remove-Item 指向前面列出的所有安全目录路径。
$itemsToDelete = @( "C:\Users\我的用户名\AppData\Local\某开发工具\Cache", "C:\Users\我的用户名\AppData\Local\Temp", "C:\Users\我的用户名\AppData\Local\CrashDumps", "C:\Users\我的用户名\AppData\Local\某浏览器\User Data\Default\Cache", "C:\Users\我的用户名\AppData\Local\某地图工具\MapCache", "C:\Users\我的用户名\AppData\Local\某音乐软件\Cache" ) foreach ($item in $itemsToDelete) { if (Test-Path $item) { Remove-Item -Path $item -Recurse -Force -ErrorAction SilentlyContinue Write-Host "已删除: $item" } else { Write-Host "不存在，跳过: $item" } }几个细节值得啰嗦一句。第一，删除前必须确认应用已经完全退出。可以打开任务管理器，看看对应进程还有没有残留在后台。第二，-ErrorAction SilentlyContinue是必须的，有些文件被系统占用时直接报错会中断整个循环。第三，删除大目录时命令行窗口里没有进度条，看着像卡死，实际上可能正在工作，尤其是文件数量多的时候。我当时删 28GB 的开发工具缓存，整整等了快一分钟没反应，差点以为出问题了。
删除完成后我重新跑了一次空间统计。C 盘可用空间从最初的 1.8GB 恢复到了大约 31GB，清理效果非常明显。
4.4 防止再次爆红的常态化操作
单次清理只能救急，如果不对根源做调整，过两个月 C 盘还会红。我做了三件事来拉长下一次爆红的间隔。
第一件事是把可以迁移的缓存路径改到其他盘。很多工具链和开发工具都支持自定义缓存目录，在配置里改一个路径就行。迁移之后，新产生的缓存不会再往 AppData 里堆，C 盘压力大幅降低。不过已经存在于老路径的缓存不会自动搬走，需要先手动删除或者迁移一次，才能完成“搬家”。
第二件事是建立定期扫描机制。我把前面生成的统计脚本保存成一个.ps1文件，设置了每月自动运行一次，输出结果到一个文本文件里。偶尔打开看一眼，C 盘的使用趋势一目了然，不用等到报警才去处理。
第三件事是系统自带的磁盘清理也不能浪费。在存储设置里开启“存储感知”，打开自动清理临时文件的开关，Windows 会定期删除临时目录里超过天数的垃圾文件。这部分工作虽然规模不大，但胜在持续，能把每天产生的细小垃圾控制在合理范围内。
5. 常见问题与踩坑记录
5.1 删完之后某些软件报错，怎么恢复
这个可能是大家最担心的问题。我这次没有遇到不可恢复的错误，但以前干过类似的事：删掉某个目录后，软件启动时提示缺少配置文件，直接卡在初始化界面。
遇到这种情况别慌，先把心态放到“可恢复”这一边。大部分配置型目录即便被删了，应用也能在下次启动时生成一份默认配置，损失的是你之前做过的自定义设置，而不是应用本身。如果真的报错，优先尝试重装软件。重装时建议选“保留用户数据”的安装方式，它通常会把丢失的配置重新初始化一遍。
有一类情况恢复不了：聊天工具里的本地数据库文件被误删，且没有同步。这种只能认命，但正因为如此，我在前面的实操里反复强调，混合数据目录必须分级处理，不能一把梭。
注意：任何删除操作前，最稳的做法是先把目标目录压缩备份一份到其他盘，确认软件运行正常再删除原目录。虽然多花一点时间，但能挡住绝大多数不必要的损失。
5.2 清理了半天，空间反而没变化是怎么回事
见过不少人抱怨：删了 10GB 的文件，磁盘可用空间还是老样子。这背后有几个常见原因。
回收站是最容易被忽略的。普通删除（非 Shift+Delete）会把文件放进回收站，磁盘空间并不会真正释放。这时候需要右键回收站图标，选择清空回收站。我用脚本里的Remove-Item带-Force参数删除，默认不走回收站，所以没碰到这个问题。
另一个原因是文件占用。有些文件正在被系统或后台进程使用，删除时会静默失败，只是没有提示。解决方案是先卸载对应的软件，确保没有进程和文件句柄残留，再用管理员身份的终端去删除。
还有一个刁钻的情况：某些盘位要求最小 1GB 的保留空间，表面显示的空间数值会有水分。配合磁盘属性里的实际容量变化查看，会更准确。
5.3 让 Codex 辅助排查时，我自己踩过的几个坑
AI 辅助不是万能的，有几个坑必须说清楚。
第一，路径必须写对。AppData 路径里的用户名如果包含空格，比如“我的用户名”，在部分工具里解析会有问题。我一开始没注意，结果统计结果全是空的。后来检查后发现，脚本里路径没有加引号，分割时把空格当成参数分隔符了。在 PowerShell 里字符串必须用引号包裹，这个细节最容易翻车。
第二，统计和删除的权限差异。统计脚本跑的时候可能会遇到“拒绝访问”的目录，这很正常。但删除的时候，如果遇到了系统组件所在路径，哪怕只是误触，风险都很高。所以删除前必须让 Codex 反过来回答一个问题：如果删掉这个目录，系统会发生什么。AI 的判断不一定绝对准确，但能多一道风险提示。
第三，Codex 生成的东西也可能正确但不符合实际需求。比如它第一次生成的脚本是全盘统计模式，会遍历整个用户目录，那速度就太慢了。这时候要在对话里追加限制条件：“只统计 AppData 下的目录，其他目录不要碰。”把约束条件越细化，输出结果越贴近实际需要。
最后的经验小结
清理 AppData 这件事，说穿了就是一个原则：先搞清楚结构，再动手删。这次用 Codex 帮我实现“分析→判断→执行”的完整链路，是我目前试过最稳的玩法。它不比我以前用磁盘分析工具多花太多时间，但多出来的那一层风险判断，几乎杜绝了误删的可能。我现在的习惯已经变成了：C 盘出问题第一反应不是打开文件管理器，而是先跑一遍统计，让 AI 告诉我这堆文件里哪些是能重新生成的，哪些是动不得的。经过这一轮操作，我的 C 盘从濒临爆满恢复到 31GB 可用空间，而且我在后续的日常使用里一直保持这种分析习惯，没有再遇到过磁盘空间的突然告急。如果你也遇到 C 盘常年吃紧、又不敢乱删的情况，不妨照这个思路走一遍，效果大概率比你想的更理想。
