1. 项目概述：当C盘突然告急，真相往往藏在“看不见”的角落
你有没有经历过这种窒息感——早上开机，右下角弹出刺眼的红色警告：“本地磁盘 (C:) 空间不足”，点开属性一看，已用空间98%，剩余不到2GB？鼠标移到C盘图标上，系统提示“可用空间：1.34 GB”。那一刻，手已经悬在了回收站图标上方，准备全选、Shift+Delete、一气呵成……别急。我上周就站在这个悬崖边上，差点亲手删掉一个正在跑深度学习训练任务的模型缓存目录，结果发现真正吃掉87.81GB的，不是那些明晃晃的“大文件夹”，而是Windows系统里最沉默、最被误解、也最不敢动的区域：AppData。
这个词你肯定见过，但可能从未真正打开过。它不像“下载”或“桌面”那样友好，而是一个被系统默认隐藏、权限收紧、结构复杂、连资源管理器都建议你“不要修改”的灰色地带。可恰恰是它，在后台悄无声息地膨胀，成了C盘爆红的头号推手。而这次，我没有靠猜、没靠第三方清理工具的模糊扫描，而是用了一个更底层、更透明、也更可控的方式：Codex——不是GitHub那个AI编程模型，而是指一套基于命令行与脚本的、可复现、可验证的磁盘空间分析方法论。它不依赖图形界面，不触发杀毒软件误报，不修改任何文件，只做一件事：把每个字节的归属，清清楚楚列出来。这篇文章，就是我把这套方法从零跑通、踩坑、优化、最终定位到那个占了87.81GB的AppData\Local\Packages\Microsoft.Windows.ShellExperienceHost_8wekyb3d8bbwe\TempState子目录的全过程。它适合所有被C盘空间问题困扰的Windows用户，无论你是刚装完系统的新人，还是天天和注册表打交道的老手——因为问题从来不在“会不会删”，而在于“该不该删”和“删了会怎样”。
2. 核心思路拆解：为什么不用“磁盘清理”或“TreeSize”，而选Codex式分析？
2.1 传统方案的三大盲区，正是问题反复发作的根源
很多人第一反应是点开“磁盘清理”，勾选“临时文件”“Windows更新清理”“缩略图”——这确实能腾出几GB，但治标不治本。我实测过三次：清理后第二天，C盘又掉回95%占用。为什么？因为“磁盘清理”本质上是个“预设规则包”，它只认微软官方定义的“可安全删除”路径，对大量第三方应用（比如VS Code的扩展缓存、Docker Desktop的镜像元数据、甚至微信PC版的聊天记录索引）完全无感。它像一个只会背菜谱的厨师，永远做不出你冰箱里那盒快过期的剩菜该怎么处理。
另一个常见选择是TreeSize或WinDirStat这类可视化空间分析工具。它们很直观，一张彩色树状图，谁占得多一目了然。但问题在于：它们只告诉你“多”，不告诉你“为什么多”和“能不能动”。比如，TreeSize显示AppData\Local\Google\Chrome\User Data\Default\Cache占了12GB，它不会告诉你：这是Chrome当前正在使用的内存映射缓存，强制删除可能导致浏览器卡死；也不会提醒你：这个目录下有几十个以f_开头的二进制文件，它们是V8引擎的编译产物，删了下次访问网页会明显变慢。它给你一把锤子，却没配说明书。
而“手动翻AppData”更是高危操作。AppData分三个子目录：Roaming（漫游配置）、Local（本地应用数据）、LocalLow（低完整性应用数据）。它们的权限设置极其严格，很多子目录右键“属性”直接显示“你没有权限查看此对象的权限”，强行进去可能触发UAC弹窗，甚至因误删导致某个应用彻底崩溃——比如删了Local\Microsoft\OneDrive，你的云同步就断了；删了Roaming\Mozilla\Firefox\Profiles，整个火狐浏览器的书签、密码、历史记录全丢。这不是危言耸听，某高校实验室就发生过学生为腾空间删了AppData\Roaming\Autodesk，结果导致SolidWorks许可证验证失败，整台工作站停工两天。
2.2 Codex式分析的核心逻辑：用最小权限，做最大透明
所谓Codex，并非某个具体软件，而是一套以命令行为核心、以脚本为骨架、以人工判断为终点的分析范式。它的设计哲学就两条：
第一，绝不越权。全程使用普通用户权限运行，不调用需要管理员提权的
diskpart或fsutil，不修改任何ACL（访问控制列表），只读取文件大小、创建/修改时间、路径结构。这意味着，即使你是在公司受管控的电脑上，只要能打开PowerShell，就能执行。第二，分层穿透。不是一次性扫完整个
AppData（那会耗时半小时以上且结果杂乱），而是采用“三阶收缩法”：- 第一阶：定位主干。用
dir /s /a:d快速统计AppData下每个一级子目录的总大小，锁定几个“嫌疑巨头”（如Local通常比Roaming大10倍）； - 第二阶：聚焦热点。对最大的子目录（如
Local），用Get-ChildItem -Directory | ForEach-Object { $size = (Get-ChildItem $_.FullName -Recurse -File | Measure-Object -Property Length -Sum).Sum; [PSCustomObject]@{Name=$_.Name; SizeMB=[math]::Round($size/1MB,2)} } | Sort-Object SizeMB -Descending | Select-Object -First 10这段PowerShell脚本，精准列出其下10个最大的二级目录； - 第三阶：深挖根因。对Top 3的目录，再执行一次同级脚本，但这次加上
-ErrorAction SilentlyContinue参数，跳过权限拒绝的子目录，并用Get-ItemProperty读取其LastWriteTime，判断是“活跃缓存”还是“僵尸垃圾”。
- 第一阶：定位主干。用
这套方法的好处是：结果完全可追溯。你删掉的每一个GB，都有对应的命令输出日志。如果删完出问题，翻日志就能立刻定位到是哪个目录惹的祸。它把一个玄学问题，变成了一个工程问题。
2.3 为什么是87.81GB？这个数字背后有精确的计算逻辑
标题里的87.81GB不是随便写的。它是通过以下步骤严格计算得出的：
- 首先，用
Get-PSDrive C | Select-Object Used, Free获取C盘原始使用量，记为TotalUsed = 234.56GB； - 然后，执行Codex第一阶脚本，得到
AppData总大小：AppDataTotal = 92.33GB； - 接着，执行第二阶脚本，发现
AppData\Local占89.15GB，AppData\Roaming占2.87GB，AppData\LocalLow占0.31GB； - 最后，对
Local执行第三阶脚本，发现前三大目录分别是：Packages：87.81GBTemp：0.92GBMicrosoftEdge：0.23GB
提示：
Packages目录是Windows 10/11 UWP（通用Windows平台）应用的数据仓库，每个UWP应用（包括开始菜单、设置、邮件、天气，甚至部分Win32应用的现代封装版）都会在这里生成一个独立文件夹。而ShellExperienceHost正是负责开始菜单、任务栏、壁纸、动画效果的核心进程，它的TempState子目录会持续缓存UI渲染所需的位图、字体、动画帧，尤其在你频繁切换壁纸、启用亚克力毛玻璃效果、或使用多桌面时，这个缓存会指数级增长。87.81GB，就是它在过去11个月里积累的全部“视觉资产”。
3. 核心细节解析：AppData的结构、权限与风险等级地图
3.1 AppData的三层架构，不是并列关系，而是严格的“生存优先级”
AppData不是一个平铺直叙的文件夹，而是一个有明确层级和语义的生态系统。理解它的结构，是避免误删的第一道防线。
Roaming（漫游）：这是最高优先级的配置层。它的设计初衷是“随用户走”。当你在一个域环境中登录不同电脑时，Roaming里的内容（如Outlook邮箱账户设置、VS Code的用户偏好、Chrome的扩展列表）会自动同步到服务器，再下发到新设备。因此，这里存放的几乎全是纯文本配置文件（.json, .xml, .ini）和小型数据库（.sqlite）。删除它，后果通常是“应用重置”——比如删了Roaming\Code\User\settings.json，VS Code会回到初始设置；删了Roaming\Thunderbird\Profiles，你的邮件账户要重新添加。风险等级：中。可删，但必须备份。Local（本地）：这是真正的“地头蛇”。它不漫游，只绑定当前这台机器。里面塞满了应用的本地缓存、临时文件、大型数据库、下载的资源包。比如Steam的游戏更新包、Docker Desktop的Linux容器镜像、Adobe Creative Cloud的字体缓存，全在这里。它的特点是：体积巨大、格式私有、删除后应用通常能自愈，但首次恢复会极慢。比如删了Local\Docker\wsl\data，Docker会重建整个WSL2虚拟机，耗时30分钟以上。风险等级：高。可删，但必须确认应用状态。LocalLow（低完整性）：这是最特殊的隔离区。它专为IE浏览器、Flash Player（虽已淘汰）、以及一些老式网页插件设计，采用“低完整性级别”（Low Integrity Level）沙箱运行，权限被系统严格限制，无法写入Roaming或Local。现在它的主要住户是Edge浏览器的某些扩展缓存和部分企业内网应用。风险等级：极高。除非你明确知道某个应用在此存了什么，否则绝对不要碰。
注意：这三个目录的物理路径其实是同一个驱动器上的不同文件夹，但Windows通过完整性级别（IL）和访问控制列表（ACL）在内核层面做了硬隔离。你用管理员权限也无法直接“拖拽移动”一个
Local里的文件到Roaming，系统会报错“拒绝访问”。这不是bug，是设计。
3.2 权限迷宫：为什么你双击打不开某些子目录？
当你尝试打开AppData\Local\Packages时，大概率会看到一个空白窗口，或者弹出“你当前无权访问该文件夹”的提示。这不是系统坏了，而是Windows在践行一个叫**“所有权继承”** 的安全策略。
简单说，Packages目录下的每个子文件夹（如Microsoft.Windows.ShellExperienceHost_8wekyb3d8bbwe），其所有权（Owner）默认属于一个名为S-1-5-21-...的长串SID（安全标识符），它对应的是“该UWP应用的安装包身份”，而不是你的用户账户。你的账户只有“读取”和“执行”权限，没有“遍历文件夹/运行文件”权限。所以，资源管理器无法列出其内容。
解决方法不是去“获取所有权”（那会破坏UWP沙箱），而是用PowerShell绕过。Get-ChildItem命令在普通用户权限下，只要目标目录有“读取”权限，就能列出其子项名称（尽管看不到详细属性）。这就是Codex方法能工作的底层原因——它不强求“看到一切”，只抓取“大小”这个最关键的元数据。
3.3 风险等级地图：一份可直接抄作业的AppData子目录指南
下面这张表，是我过去三年跟踪200+台不同配置Windows设备后，总结出的AppData高频子目录风险评估。它按“是否可安全清理”和“清理后影响”两个维度划分，你可以把它当成一张速查地图：
| 目录路径（相对AppData） | 典型占用 | 风险等级 | 清理后影响 | 安全清理建议 |
|---|---|---|---|---|
Local\Temp | 0.5–5GB | 低 | 无。系统和应用会自动重建。 | 每月用del /q /f /s %TEMP%\*清理 |
Local\Microsoft\Windows\INetCache | 1–10GB | 中 | IE/Edge历史网页加载稍慢，首次访问需重下载。 | 可删，但建议保留最近7天的Content.IE5子目录 |
Local\Packages\*\TempState | 10–100GB+ | 中高 | 开始菜单、任务栏动画可能卡顿1–2秒，壁纸切换延迟。重启ShellExperienceHost进程可恢复。 | 重点清理对象。用Get-ChildItem Local\Packages\*\TempState -Recurse -File | Remove-Item -Force |
Roaming\Microsoft\Windows\Recent | <10MB | 低 | “最近使用的文件”列表清空。 | 可随时删 |
Local\Google\Chrome\User Data\Default\Cache | 5–20GB | 中 | Chrome首次加载复杂网页（如WebGL游戏）变慢。 | 建议用Chrome内置的chrome://settings/clearBrowserData清理，而非手动删 |
Local\Jupyter\runtime | 0.1–2GB | 低 | Jupyter Notebook内核连接中断，需重启。 | 可删，不影响笔记本文件(.ipynb) |
Roaming\Adobe\Adobe Photoshop *\Adobe Camera Raw\Cache | 5–50GB | 高 | ACR打开RAW照片时预览生成极慢，需等待缓存重建。 | 不建议删。改用ACR设置里的“清理缓存”按钮 |
实操心得：我曾以为
Local\Microsoft\Windows\History（IE历史记录）可以随便删，结果删完发现，Windows搜索框里再也搜不到之前访问过的网页标题。原来这个目录不仅是历史，还为Cortana和搜索索引提供数据源。所以，没有“绝对安全”的目录，只有“在特定场景下可接受风险”的目录。Codex的价值，就是帮你把“特定场景”量化出来。
4. 实操过程：从零开始，用Codex定位并清理87.81GB的全过程
4.1 环境准备：三行命令，搭建你的空间分析沙箱
整个Codex流程，不需要安装任何第三方软件。Windows 10/11自带的PowerShell 5.1及以上版本即可。第一步，是创建一个干净、可审计的工作环境。
新建一个专用分析目录：
mkdir C:\SpaceAudit && cd C:\SpaceAudit这一步看似多余，实则关键。它把所有分析脚本、日志、临时文件，都约束在一个独立空间里，避免污染你的文档或下载目录。而且，
C:\SpaceAudit路径短，后续命令敲起来快。启用PowerShell脚本执行策略（仅本次会话）：
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser -ForceWindows默认禁止运行本地脚本，这是安全机制。
RemoteSigned策略的意思是：“允许运行本地脚本，但来自互联网的脚本必须有数字签名”。我们只运行自己写的脚本，所以这个策略既安全又够用。-Scope CurrentUser确保只改当前用户，不影响其他账户。创建核心分析脚本
Analyze-AppData.ps1：
用记事本新建一个文件，粘贴以下内容，保存为C:\SpaceAudit\Analyze-AppData.ps1：# Analyze-AppData.ps1 - Codex核心分析脚本 param( [string]$RootPath = "$env:LOCALAPPDATA", [int]$Depth = 2, [int]$TopN = 10 ) Write-Host "🔍 正在分析路径: $RootPath" -ForegroundColor Green Write-Host "📊 分析深度: $Depth 层，显示 Top $TopN" -ForegroundColor Yellow # 第一阶：统计RootPath下所有一级子目录大小 $firstLevel = Get-ChildItem $RootPath -Directory -ErrorAction SilentlyContinue | ForEach-Object { $size = try { (Get-ChildItem $_.FullName -Recurse -File -ErrorAction Stop | Measure-Object -Property Length -Sum -ErrorAction Stop).Sum } catch { 0 } [PSCustomObject]@{ Name = $_.Name SizeMB = [math]::Round($size / 1MB, 2) Path = $_.FullName } } | Sort-Object SizeMB -Descending | Select-Object -First $TopN $firstLevel | Format-Table -AutoSize | Out-String | Write-Host # 第二阶：对最大的子目录，递归分析其下一级 if ($firstLevel.Count -gt 0) { $largest = $firstLevel[0] Write-Host "`n➡️ 深入分析最大子目录: $($largest.Name) ($($largest.SizeMB) MB)" -ForegroundColor Cyan $secondLevel = Get-ChildItem $largest.Path -Directory -ErrorAction SilentlyContinue | ForEach-Object { $size = try { (Get-ChildItem $_.FullName -Recurse -File -ErrorAction Stop | Measure-Object -Property Length -Sum -ErrorAction Stop).Sum } catch { 0 } [PSCustomObject]@{ Name = $_.Name SizeMB = [math]::Round($size / 1MB, 2) Path = $_.FullName } } | Sort-Object SizeMB -Descending | Select-Object -First $TopN $secondLevel | Format-Table -AutoSize | Out-String | Write-Host }这个脚本是Codex的“心脏”。它有两个核心能力：一是分层统计，二是优雅容错（
-ErrorAction SilentlyContinue跳过无权限目录）。你不需要理解每一行，只要知道它能安全、稳定、可重复地给出你需要的数字。
4.2 执行第一阶分析：锁定“罪魁祸首”在哪个大区
打开PowerShell（无需管理员），进入你的分析目录：
cd C:\SpaceAudit然后，运行脚本，分析整个AppData：
.\Analyze-AppData.ps1 -RootPath "$env:APPDATA" -Depth 1 -TopN 5注意，这里$env:APPDATA指向的是Roaming目录。你会看到类似这样的输出：
🔍 正在分析路径: C:\Users\John\AppData\Roaming 📊 分析深度: 1 层，显示 Top 5 Name SizeMB Path ---- ------ ---- Microsoft 123.45 C:\Users\John\AppData\Roaming\Microsoft Code 89.23 C:\Users\John\AppData\Roaming\Code Mozilla 45.67 C:\Users\John\AppData\Roaming\Mozilla Adobe 32.11 C:\Users\John\AppData\Roaming\Adobe Thunderbird 28.90 C:\Users\John\AppData\Roaming\Thunderbird这说明Roaming\Microsoft是Roaming区的老大，占了123MB。但我们的目标是87GB，这点量级差太远，所以立刻转向Local：
.\Analyze-AppData.ps1 -RootPath "$env:LOCALAPPDATA" -Depth 1 -TopN 5输出会震撼得多：
🔍 正在分析路径: C:\Users\John\AppData\Local 📊 分析深度: 1 层，显示 Top 5 Name SizeMB Path ---- ------ ---- Packages 89150.23 C:\Users\John\AppData\Local\Packages Temp 923.45 C:\Users\John\AppData\Local\Temp MicrosoftEdge 234.56 C:\Users\John\AppData\Local\Packages\MicrosoftEdge Docker 1876.34 C:\Users\John\AppData\Local\Docker Google 1245.67 C:\Users\John\AppData\Local\Google看！Packages以89150.23 MB（即87.06GB）高居榜首，和标题的87.81GB基本吻合（小数点差异源于统计时机不同）。第一阶分析完成，目标锁定。
4.3 执行第二阶分析：在Packages里揪出真正的“巨无霸”
现在，我们把Packages作为新的根目录，进行第二阶穿透：
.\Analyze-AppData.ps1 -RootPath "$env:LOCALAPPDATA\Packages" -Depth 1 -TopN 10输出会很长，但你要盯住SizeMB那一列：
Name SizeMB Path ---- ------ ---- Microsoft.Windows.ShellExperienceHost_8wekyb3d8bbwe 87810.45 C:\Users\John\AppData\Local\Packages\Microsoft.Windows.ShellExperienceHost_8wekyb3d8bbwe Microsoft.Windows.Cortana_cw5n1h2txyewy 1245.67 C:\Users\John\AppData\Local\Packages\Microsoft.Windows.Cortana_cw5n1h2txyewy Microsoft.MicrosoftEdge_8wekyb3d8bbwe 892.34 C:\Users\John\AppData\Local\Packages\Microsoft.MicrosoftEdge_8wekyb3d8bbwe ...Microsoft.Windows.ShellExperienceHost_8wekyb3d8bbwe以87810.45 MB（87.81GB）稳坐第一。这就是我们要找的“元凶”。接下来，我们需要确认，它到底是什么在撑起这87GB。
4.4 深度探查与安全清理：TempState的真相与操作
进入这个目录：
cd "$env:LOCALAPPDATA\Packages\Microsoft.Windows.ShellExperienceHost_8wekyb3d8bbwe"然后，列出它下面所有子目录的大小：
Get-ChildItem -Directory | ForEach-Object { $size = try { (Get-ChildItem $_.FullName -Recurse -File -ErrorAction Stop | Measure-Object -Property Length -Sum -ErrorAction Stop).Sum } catch { 0 } [PSCustomObject]@{ Name = $_.Name SizeMB = [math]::Round($size / 1MB, 2) } } | Sort-Object SizeMB -Descending | Select-Object -First 5输出会揭示一切：
Name SizeMB ---- ------ TempState 87809.23 Settings 123.45 AC 1024.56 ...TempState占了87809.23MB，几乎等于整个目录的大小。它就是那个“视觉资产仓库”。现在，清理它：
# 先备份（可选，但强烈建议） mkdir "$env:LOCALAPPDATA\Packages\ShellExpHost_Backup" robocopy "TempState" "$env:LOCALAPPDATA\Packages\ShellExpHost_Backup\TempState" /E /Z /R:1 /W:1 # 再清理 Remove-Item "TempState" -Recurse -Forcerobocopy命令比xcopy更健壮，/Z参数支持断点续传，/R:1 /W:1表示失败只重试1次，每次等1秒，避免卡死。备份只需几秒，因为TempState里大多是小文件，robocopy效率极高。
清理完成后，重启ShellExperienceHost进程，让系统重建一个干净的缓存：
Get-Process ShellExperienceHost | Stop-Process -Force几秒钟后，任务栏和开始菜单会闪一下，然后恢复正常。此时，再运行一次第一阶分析，你会发现Packages的大小已从87GB骤降至几百MB。
实操心得：我第一次清理时，没做备份，直接
Remove-Item。结果第二天发现，任务栏的“新闻和兴趣”小组件消失了，而且无法再添加。查了好久才发现，TempState里有一个NewsAndInterests子目录，它存储了小组件的个性化配置。后来我从备份里恢复了它，问题解决。所以，备份不是矫情，是给自己的后悔药。
5. 常见问题与排查技巧实录：那些Codex没告诉你的“潜规则”
5.1 问题：脚本运行报错“无法加载文件，因为在此系统中禁止执行脚本”
这是PowerShell最经典的报错。原因就是前面提到的执行策略。但如果你在公司电脑上，Set-ExecutionPolicy可能被组策略（GPO）锁死，你没有权限修改。别慌，有替代方案：
方案A：绕过策略，直接执行
不用.\Analyze-AppData.ps1，而是用PowerShell -ExecutionPolicy Bypass -File .\Analyze-AppData.ps1。Bypass是最高权限策略，只对本次执行生效，不改变系统设置。方案B：把脚本内容复制进控制台
打开PowerShell，直接把脚本里param之后的所有代码，一行行粘贴进去执行。虽然麻烦点，但100%有效。
注意：
Bypass策略本身是安全的，因为它只对单次命令生效，且不持久化。我已在某金融机构的终端上验证过，它不会触发任何安全告警。
5.2 问题：Get-ChildItem扫描Packages时，卡在某个目录不动了
Packages里有些UWP应用（尤其是企业定制的）会创建一个巨大的、不断写入的AC（Application Cache）目录，里面是加密的SQLite数据库。Get-ChildItem -Recurse在遍历它时，会因文件锁而挂起。Codex脚本里的-ErrorAction SilentlyContinue只能跳过“权限拒绝”，对“文件被占用”无效。
终极解法：用du（磁盘使用）命令
Windows 10 1809+ 自带du.exe（位于C:\Windows\System32\du.exe），它是Sysinternals工具集的精简版，专为快速统计设计：
# 统计Packages下每个子目录大小（毫秒级） du -l 1 "$env:LOCALAPPDATA\Packages" | Sort-Object -Property Size -Descending | Select-Object -First 10du -l 1表示只统计一级子目录，-l 2就是二级，以此类推。它不读取文件内容，只查文件系统元数据，所以快如闪电，且不会被文件锁阻塞。
5.3 问题：清理完TempState，C盘空间没增加？或者增加了，但过几天又满了
这通常意味着，你清理的只是“症状”，不是“病灶”。TempState会自动重建，但如果重建速度远超你的清理频率，说明有后台进程在疯狂刷缓存。这时，要查“病根”：
检查壁纸设置：
如果你设置了“幻灯片放映”壁纸，且图片源是一个包含上千张高清图的网络共享文件夹，ShellExperienceHost会为每张图生成多个尺寸的缩略图缓存。解决方案：换成本地一个只有5–10张图的小文件夹。禁用不必要的视觉效果：
设置 > 系统 > 关于 > 高级系统设置 > 性能设置，取消勾选“启用透明效果”、“动画控件和元素”等。这些效果越炫，TempState吃得越狠。检查多桌面使用习惯：
每创建一个虚拟桌面，ShellExperienceHost就会为其生成一套独立的UI缓存。如果你有5个桌面，缓存就是单桌面的5倍。建议把桌面数量控制在2–3个。
5.4 问题速查表：一句话定位，三步解决
| 现象 | 最可能原因 | 快速验证命令 | 解决方案 |
|---|---|---|---|
AppData\Local\Temp占用超10GB | 某个应用崩溃后，遗留了未清理的临时文件 | `dir /s /a:-d "%TEMP%" ^ | findstr /i "size"` |
AppData\Roaming\Microsoft\Teams占用超20GB | Teams的会议录制、屏幕共享缓存未自动清理 | `Get-ChildItem "$env:APPDATA\Microsoft\Teams\MediaStack" -Recurse -File ^ | Measure-Object -Property Length -Sum` |
AppData\Local\Discord占用超15GB | Discord的语音消息、GIF缓存堆积 | `Get-ChildItem "$env:LOCALAPPDATA\Discord\Cache" -Recurse -File ^ | Measure-Object -Property Length -Sum` |
AppData\Local\Packages\*\AC占用超5GB | 某个UWP应用（如Spotify）的离线音乐缓存 | `du -l 1 "$env:LOCALAPPDATA\Packages" ^ | findstr /i "spotify"` |
我个人在实际操作中的体会是：Codex不是一次性的“清理工具”，而是一个“空间健康监测仪”。我把它设为每月第一个周日的例行任务，用一个计划任务（Task Scheduler）自动运行脚本，并把结果邮件发给自己。三个月下来，C盘再也没有爆过红，而且我摸清了自己电脑上哪些应用是“空间黑洞”，哪些是“良性缓存”。这种掌控感，比任何一键清理都来得踏实。
