企业官网建设流程全解析

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 而不是直接装一个 WinDirStat

2.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 大概 20GB，Downloads 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；
• 系统临时文件目录 Temp，8.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 是怎么组成的

这次清理前，我做了一张表格记录现场数据，给你参考：

加起来正好在 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 盘时，多一分从容，少一分冲动。