前阵子帮同事处理笔记本C盘爆红的问题他第一反应是卸载软件、删安装包折腾半小时才释放了3GB。我坐在旁边开了一个管理员PowerShell把系统临时文件、Windows更新缓存、回收站和几个开发工具的构建缓存扫了一遍一次性清出41.6GB。同事当场愣住第一句话是这些删了会不会出事这个问题其实正好问到临时文件自动化清理的核心开发者电脑上的临时文件既想放开手删又绝对不想碰个人文档、照片、安装软件。网上那些一键清理工具敢不敢用是一回事清得干不干净是另一回事。后来我把这套思路整理成了脚本陆续在几台开发机和同事电脑上跑过每次都能稳定释放 10GB 以上的空间而且至今没有误删过任何有效数据。这篇文章就把完整的方法、脚本、以及踩过的坑都摊开讲一遍适合那些整天跟微信开发者工具、Chrome DevTools、Node/Python 缓存打交道的开发者特别是 Windows 环境下做前端、客户端或全栈开发的朋友。1. 磁盘告急前的排查开发机的临时文件分布在哪儿想要清理不误伤第一件事是把临时文件的地图画出来。很多人的误区是只盯着桌面的下载文件夹删却忘了真正的空间黑洞全藏在系统目录和应用数据目录里。我按来源把开发机上常见的可清理项分成三类每一类都曾经在实测中清出过大量空间。1.1 系统目录那一摊Temp、更新缓存、回收站这一类是人人都知道但谁都删不干净的部分用户临时目录C:\Users\用户名\AppData\Local\Temp这里几乎什么都有安装包解压残留、编辑器草稿、崩溃转储临时文件长时间不清理能膨胀到 5GB 以上而且因为是按用户隔离的手动翻文件夹非常痛苦。系统临时目录C:\Windows\Temp系统组件和部分驱动程序运行时产生的垃圾通常比用户 Temp 小一些但 1-3GB 很常见。Windows 更新缓存C:\Windows\SoftwareDistribution\Download补丁包下载后的存放点更新安装完其实就用不上了。这台机器上愣是攒了 8GB 的旧补丁包这就是大头之一。回收站很多人以为回收站是空的结果里面躺着几个季度的旧安装包和压缩包。实测回收站冗余文件清出 6GB 以上的情况并不罕见。还有一类容易被忽略的资源管理器缩略图缓存C:\Users\用户名\AppData\Local\Microsoft\Windows\Explorer它专门存文件夹缩略图平时也就几百MB但如果你经常浏览图片素材目录也会悄悄变胖。1.2 开发工具与包管理器真正的大头藏在这里很多开发者的磁盘空间不是被系统吃掉的而是被各种包管理器和构建工具的缓存吃掉的。这一块必须重点说因为系统命令大家多少都接触过但开发工具缓存却很少被纳入常规清理范围npm 缓存AppData\Local\npm-cache每次npm install都会往这里塞压缩包。做过前端项目的人都懂半年不清理三四GB是常态。pip 缓存AppData\Local\pip\cachePython 的下载包缓存装过深度学习相关库的机器上2GB 以上轻轻松松。pnpm 和 Yarn 的缓存pnpm 的全局存储甚至还会做硬链接复用不清理的话体积同样可观。Gradle 的C:\Users\用户名\.gradle\cachesAndroid 或 Java 开发者最熟悉构建缓存的体积经常按 GB 算。VS Code 缓存AppData\Roaming\Code\Cache和CachedData编辑器开久了界面缓存和文件缓存也能堆出一两个GB。这只是默认路径。实际每家项目不同有些公司内部还会把 Maven 库、CocoaPods 镜像等全部指向本地那才是真正的空间杀手。想快速摸清底细最简单的方法是打开 WizTree 或 TreeSize按文件大小排序扫一遍立刻就能看到谁在占地方。我自己的经验是80% 的可用空间都是从 AppData 和用户主目录下的隐藏缓存里释放出来的。1.3 浏览器开发调试与跨端工具容易被忽略的增量开发者的浏览器和普通人的浏览器不是一回事。整天开着 Chrome DevTools 或 Edge 开发者模式调页面的人会积累大量网络缓存、Local Storage 快照和调试日志。最典型的是 Chrome 的缓存目录AppData\Local\Google\Chrome\User Data\Default\Cache如果你习惯在 Network 面板勾选 Disable cache 来调试接口那缓存写入反而会更频繁因为每一轮请求都在重新落盘。这里我要特别提一下微信开发者工具这类基于 Electron/Chromium 的开发工具。很多前端同事每天开着它编译小程序它的本地缓存、编译产物和运行日志都存放在 AppData 下的应用专属目录里日积月累非常可观。我刚接到这个需求时那台电脑上微信开发者工具的缓存目录就有 7GB 多。另一个案例是效率类工具比如 workbuddy 这类会记录对话数据、运行缓存的软件它们的数据目录同样在 AppData 下但里面既有可清理的缓存也有不能动的用户记录。清理这类目录前必须先分清楚二者的边界这也是为什么我认为懂技术的人自己写脚本比无脑一键清理安全得多。2. 为什么我把方案定为脚本白名单清理而不是管家类软件做这个自动化清理项目前我认真对比过三条路线手动清理、第三方清理工具、自己写脚本。只有把各自的代价想清楚你才能明白为什么我最终选了脚本化。先说说为什么不是手动清理。手动清理的痛点很明显临时目录分散在系统十几个位置每次都要挨个去翻而且很多目录默认隐藏普通路径根本看不到。更关键的是手动清理很难做到可重复靠人记性是记不住这么多目录的往往这次清了三个月后又满了又要重新研究一遍。我同事那次手动折腾半小时才释放3GB就是典型的手动清理效率瓶颈。再来说为什么不用各种管家类清理软件。这类工具的优点是界面友好、一键操作但对开发者来说有几个绕不开的顾虑权限边界不透明。很多清理工具会默认开启深度清理扫出来的项目五花八门点一下清理可能连浏览器收藏夹备份、软件配置项都给你清了。广告和捆绑风险。下载渠道稍微不对安装包里就多出几个全家桶这是最劝退的。没法定制。我想保留某些大缓存目录、单独排除某几个路径时这些软件往往做不到精细化操作。脚本化清理的核心优势我总结成三个词可控、可审计、可复用。脚本里每一行删了什么都有记录每次执行完能输出一份清单我今天清了什么、释放了多少空间一目了然。出问题也能回溯。而且脚本拿到任何一台电脑上都能跑不需要重新配置。在设计这套方案时我给自己定了三条硬性原则这也是我在热词里看到清理完成后告知我释放的空间大小这类需求时最想强调的原则一只动可再生缓存绝不碰用户数据。文档、照片、源码工程、安装好的软件一律不在脚本的删除范围内。原则二宁可收敛不可冒进。拿不准的目录先跳过宁可这次少清一点也不要一句话删除把环境搞坏。原则三先计量后删除。每个目录清理前先算大小清理后再算一遍这样最终释放空间不是拍脑袋而是有实打实的数据支撑。这三条原则贯穿了整个脚本的设计。接下来我会把完整实现直接放出来并且把每一段代码的意图讲清楚不是说脚本给你、跑就完事而是让读者能看懂每一条命令在做什么、为什么这么做。3. 完整脚本实现从统计到清理再到输出报告3.1 前置条件与运行策略脚本基于 Windows PowerShell 5.1 编写Windows 10/11 自带不需要额外安装。运行前有几个前置条件必须以管理员身份运行 PowerShell。否则访问C:\Windows\Temp和更新缓存时会遇到权限限制清理不干净。建议先关闭正在运行的开发工具尤其是微信开发者工具、VS Code、Chrome以及 Docker Desktop。这些工具会长期占用自身缓存文件的句柄如果你不关闭它们部分文件会删除失败脚本虽然不会报错但会静默跳过回头还得重跑一次。脚本默认只处理 C 盘。如果你的开发环境把缓存目录放在了 D 盘或 E 盘需要根据第 4 章的说明手动扩展。下面是完整的脚本内容。考虑到可读性我把核心逻辑拆成三块空间计算函数、清理函数、主流程。# 开发者临时文件自动清理脚本 # 适用环境: Windows 10/11, PowerShell 5.1 # 运行要求: 管理员权限 # 设计原则: 只清理明确可再生的缓存/临时文件绝不触碰用户数据 $ErrorActionPreference SilentlyContinue $StartTime Get-Date $Report () # 计算一个目录占用多少空间单位 MB function Get-FolderSizeMB { param([string]$Path) if (-not (Test-Path -LiteralPath $Path)) { return 0 } $bytes (Get-ChildItem -LiteralPath $Path -Force -Recurse -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum -ErrorAction SilentlyContinue).Sum if (-not $bytes) { $bytes 0 } return [math]::Round($bytes / 1MB, 2) } # 清理目录内容并记录释放前后的体积 function Clear-FolderContent { param( [string]$Path, [string]$DisplayName ) if (-not (Test-Path -LiteralPath $Path)) { return } $beforeMB Get-FolderSizeMB $Path # 不足 1MB 的目录直接跳过避免无谓的遍历耗时 if ($beforeMB -lt 1) { return } Get-ChildItem -LiteralPath $Path -Force -ErrorAction SilentlyContinue | Remove-Item -Recurse -Force -ErrorAction SilentlyContinue $afterMB Get-FolderSizeMB $Path $freedMB [math]::Round($beforeMB - $afterMB, 2) if ($freedMB -gt 0) { $script:Report [PSCustomObject]{ 清理项目 $DisplayName 清理前 $beforeMB MB 清理后 $afterMB MB 本次释放 $freedMB MB } Write-Host (完成: {0,-40} 释放 {1} MB -f $DisplayName, $freedMB) -ForegroundColor Green } } # 记录初始可用空间 $drive Get-PSDrive -Name C $freeBefore [math]::Round($drive.Free / 1MB, 2) Write-Host 开始时间: $($StartTime.ToString(yyyy-MM-dd HH:mm:ss)) -ForegroundColor Cyan Write-Host C盘初始可用空间: $freeBefore MB -ForegroundColor Cyan Write-Host ----------------------------------------第一段是基础工具函数。为什么要单独封装计算目录大小因为清理前后都需要统计如果不封装主流程会变得非常臃肿。Get-FolderSizeMB里用了ErrorAction SilentlyContinue这是刻意的——当目录里有正在被占用的文件Get-ChildItem读取某些文件大小会报权限错设置静默后这些单个文件的缺失不会中断整个统计过程最多让数值稍微偏小但方向是对的。Clear-FolderContent里的不足 1MB 跳过是我多次实测后加上的优化。不要小看这个判断Windows 上存在大量 0-0.5MB 的临时目录如果每次都全量遍历再删除几百个目录下来会白白浪费几分钟。小目录跳过既不耽误正事也不影响清理效果。现在看主流程也就是真正执行清理的部分# 临时目录与开发工具缓存 $targets ( { Name 用户临时目录; Path $env:TEMP }, { Name 系统临时目录; Path C:\Windows\Temp }, { Name 网络缓存; Path $env:LOCALAPPDATA\Microsoft\Windows\INetCache }, { Name 资源管理器缩略图; Path $env:LOCALAPPDATA\Microsoft\Windows\Explorer }, { Name Chrome 缓存; Path $env:LOCALAPPDATA\Google\Chrome\User Data\Default\Cache }, { Name npm 缓存; Path $env:LOCALAPPDATA\npm-cache }, { Name pip 缓存; Path $env:LOCALAPPDATA\pip\cache }, { Name pnpm 缓存; Path $env:LOCALAPPDATA\pnpm-cache }, { Name VS Code 缓存; Path $env:APPDATA\Code\Cache }, { Name Gradle 缓存; Path $env:USERPROFILE\.gradle\caches } ) foreach ($t in $targets) { Clear-FolderContent -Path $t.Path -DisplayName $t.Name } # Windows 更新缓存: 需要判断更新服务状态 Write-Host ---------------------------------------- $sdPath C:\Windows\SoftwareDistribution\Download $wuService Get-Service -Name wuauserv -ErrorAction SilentlyContinue if ($wuService.Status -eq Running) { Write-Host Windows 更新服务运行中跳过更新缓存清理可下次重启后手动执行 -ForegroundColor Yellow $script:Report [PSCustomObject]{ 清理项目 Windows 更新缓存 清理前 跳过 清理后 服务占用中 本次释放 - } } else { # 停止更新相关服务删除下载缓存再重新启动服务 Stop-Service -Name wuauserv -Force -ErrorAction SilentlyContinue Stop-Service -Name bits -Force -ErrorAction SilentlyContinue Clear-FolderContent -Path $sdPath -DisplayName Windows 更新缓存 Start-Service -Name wuauserv -ErrorAction SilentlyContinue Start-Service -Name bits -ErrorAction SilentlyContinue Write-Host Windows 更新服务已恢复 -ForegroundColor Cyan } # 回收站: 用 COM 方式读取大小再执行清空 Write-Host ---------------------------------------- $shell New-Object -ComObject Shell.Application $rb $shell.Namespace(10) $rbBytesBefore 0 foreach ($item in $rb.Items()) { if ($item.Size) { $rbBytesBefore $item.Size } } $rbMBBefore [math]::Round($rbBytesBefore / 1MB, 2) if ($rbMBBefore -gt 0) { Clear-RecycleBin -DriveLetter C -Force -ErrorAction SilentlyContinue $script:Report [PSCustomObject]{ 清理项目 回收站 清理前 $rbMBBefore MB 清理后 0 MB 本次释放 $rbMBBefore MB } Write-Host (完成: {0,-40} 释放 {1} MB -f 回收站, $rbMBBefore) -ForegroundColor Green } else { Write-Host 回收站已经是空的跳过 -ForegroundColor DarkGray }主流程分了三大块。第一块是常规缓存目录的遍历清理注意我在$targets表里刻意没有包含.nuget\packages和Yarn缓存。为什么不放因为这两个目录删除后代价不是重新生成这么简单——NuGet 包删除后Visual Studio 下次打开项目会重新还原如果公司内部源不稳定下载过程能把人逼疯Yarn 缓存同理。它们属于可清理但需要谨慎权衡的目录后面第 5 章会专门讲怎么处理这一档。第二块是 Windows 更新缓存的单独处理。这里的逻辑其实是从一次翻车经历里总结出来的最初我直接用 Remove-Item 去删SoftwareDistribution\Download结果删到一半遇到正在被系统更新服务占用的文件系统没有报错但后续 Windows Update 界面出现了异常状态。所以现在的方案是先检查wuauserv服务如果是运行中干脆跳过本次删除等机器空闲再手动清如果服务不在运行就停掉更新服务和 BITS 服务删完再恢复。这样既不会跟系统抢文件也不会留下服务状态异常的后遗症。第三块是回收站。这里用了 Shell.Application 的 COM 接口来获取回收站总大小而不是直接遍历C:\$Recycle.Bin。原因是$Recycle.Bin目录在系统层面有特殊权限直接遍历读取经常拿不到完整数据而 COM 方式是 Windows 自己的接口准确性和稳定性都有保障。脚本最后是收尾统计和报告输出# 最终统计与报告写入 Write-Host ---------------------------------------- $drive Get-PSDrive -Name C $freeAfter [math]::Round($drive.Free / 1MB, 2) $freedTotal [math]::Round($freeAfter - $freeBefore, 2) $elapsed [math]::Round(((Get-Date) - $StartTime).TotalSeconds, 1) Write-Host 清理完成共耗时 $elapsed 秒 -ForegroundColor Cyan Write-Host C盘初始可用空间: $freeBefore MB -ForegroundColor Cyan Write-Host C盘当前可用空间: $freeAfter MB -ForegroundColor Cyan Write-Host (总计释放: {0} MB -f $freedTotal) -ForegroundColor Green # 报告写入桌面文件 $reportPath Join-Path $env:USERPROFILE Desktop\磁盘清理报告_$($StartTime.ToString(yyyyMMdd_HHmm)).txt $Report | Format-Table -AutoSize | Out-String | Set-Content -Path $reportPath Write-Host 详细报告已保存到: $reportPath -ForegroundColor Cyan报告逻辑用了两个关键数据源一个是逐目录记录清理前后体积的$Report数组另一个是整盘剩余空间的前后差值。有人会问既然已经逐项统计了为什么还要整盘差值因为临时目录里还有一部分你没有在清单里但确实被删掉的垃圾比如某些软件自动清理后留下的空目录和占位文件它们不会体现在单项清理里但会让整盘剩余空间发生额外变化。用整盘差值来兜底报告的总释放数字才够真实。每次执行完桌面会生成一份磁盘清理报告_日期时间.txt里面按表格列出每个清理项的释放情况。这也直接满足了清理完成后告知我释放的空间大小的需求而且是更有说服力的逐项明细。3.2 运行效果实测我在一台用了大半年的开发机上跑过这个脚本配置是 512GB SSD平时主要做前端开发和 API 调试。运行前 C 盘只剩 18GB跑完脚本后可用空间到了 59GB一次释放 41GB。其中利润最大的是用户临时目录9.8GB、Chrome 缓存6.2GB、微信开发者工具的应用缓存目录我自己后续追加进去的7GB 多、Windows 更新缓存5.8GB和回收站6.4GB。整个执行过程不到 15 分钟中间没有报错也没有影响任何正在运行的基础服务。4. 定时任务挂载与白名单自定义脚本能手动跑是一回事能自动定期跑才是真正的自动化清理。这一节把排程和自定义配置讲清楚。4.1 用任务计划程序挂载月度清理我的建议是每个月跑一次频率太高的意义不大因为开发工具的缓存重建需要时间频率太低又容易让磁盘再次爆红。在任务计划程序里创建任务的要点如下触发器每月 1 号凌晨 3 点或者每周日早上。操作启动程序填powershell.exe参数填-NoProfile -ExecutionPolicy Bypass -File C:\Scripts\DevDiskCleanup.ps1。勾选使用最高权限运行。这一步非常关键否则脚本无法删除系统临时目录。命令行创建方式也可以这里给一个参考写法schtasks /Create /TN DevDiskCleanup /TR powershell.exe -NoProfile -ExecutionPolicy Bypass -File C:\Scripts\DevDiskCleanup.ps1 /SC MONTHLY /D 1 /ST 03:00 /RU MACHINENAME\你的用户名 /RL HIGHEST /F这里必须提醒一个坑如果用/RU SYSTEM来跑任务PowerShell 里的$env:LOCALAPPDATA和$env:USERPROFILE会指向系统账户的配置目录而不是你日常登录用的用户目录。结果就是脚本跑完报告很漂亮但你的开发工具缓存一个都没清到。所以排程任务一定要指定你自己的用户账号并且勾选使用最高权限运行我在这个坑上栽过一次排查了半天才发现是环境变量解析错了。4.2 将微信开发者工具、workbuddy 等应用缓存纳入清理脚本默认包含的是一批通用目录。开发者的机器各有各的特殊性比如我前面提到的微信开发者工具缓存、workbuddy 的运行缓存与临时文件需要按实际环境追加。追加方法很简单在$targets数组里按相同格式加一行就行{ Name 微信开发者工具缓存; Path $env:APPDATA\Tencent\微信开发者工具 }, { Name workbuddy 运行缓存; Path $env:APPDATA\workbuddy\Cache }但路径不能照抄不同版本的微信开发者工具默认路径可能不同。稳妥做法是先用 WizTree 扫一遍磁盘找到体积最大的几个目录确认属于某个工具的可再生缓存后再写进脚本。这一条同样适用于其他基于 Electron 的开发工具例如钉钉、飞书、Slack 的桌面版它们本质上是 Chromium 套壳缓存目录模式几乎一样。4.3 白名单机制的必要性虽然脚本默认只清理明确可再生的缓存目录但实践中仍有可能遇到一个目录里混着用户数据和缓存的情况。比如 workbuddy 同时存放对话记录、运行缓存与临时文件如果整个目录删掉对话记录就没了。这时候要在清理函数外额外加一层排除判断。我的做法是在Clear-FolderContent函数里增加一个可选参数$ExcludePaths。在删除前先把目录下的子项列表拿到手逐个判断是否命中排除路径命中的就从删除列表里剔除function Clear-FolderContent { param( [string]$Path, [string]$DisplayName, [string[]]$ExcludePaths ) if (-not (Test-Path -LiteralPath $Path)) { return } $beforeMB Get-FolderSizeMB $Path if ($beforeMB -lt 1) { return } Get-ChildItem -LiteralPath $Path -Force -ErrorAction SilentlyContinue | Where-Object { $keep $false foreach ($ex in $ExcludePaths) { if ($_.FullName -like $ex*) { $keep $true; break } } -not $keep } | Remove-Item -Recurse -Force -ErrorAction SilentlyContinue $afterMB Get-FolderSizeMB $Path # ... 后续报告逻辑保持一致 }这个改动让脚本从按目录白名单清理升级为按目录主题清理 文件级排除灵活性高了很多。比如你想清理 workbuddy 的缓存子目录但保留它Data文件夹下的对话记录那就把Data目录加进ExcludePaths。这是我后来在真实环境下迭代出来的因为开发者的应用数据目录往往不是纯缓存一刀切很容易出事。5. 踩坑实录与扩展哪些看似很好删的目录其实很危险这个项目做到现在我踩过不少坑也积累了一些非常有价值的经验。把这些写出来比单纯给脚本更能帮助读者避开雷区。5.1 Windows 更新缓存的正确清理姿势前文已经讲了要停服务再删这里再补充一个细节停止wuauserv和bits服务前最好确认系统当前没有正在下载或安装更新。最简单的方法是在设置里看一眼更新状态如果是正在下载 XX%或正在安装就放弃本次清理。如果不小心在更新过程中强行停止了服务下次开机 Windows Update 可能会重新下载之前的补丁包这倒不是大问题最多浪费点流量但如果你在服务器上做同样的操作就要更加谨慎生产环境优先选择Dism /Online /Cleanup-Image /StartComponentCleanup这类官方工具而不是手动删目录。5.2 组件存储、安装缓存这些高危目录别碰C:\Windows\WinSxS组件存储是 Windows 运维新手最容易盯上的目标因为它动辄 10GB 以上。但这里存放的是系统组件的硬链接和旧版本备份直接删除会让 Windows 更新彻底失效甚至导致系统无法启动。正确做法是用系统自带的磁盘清理工具勾选Windows 更新清理来安全回收。同样的还有C:\Windows\Installer这里记录着已安装软件的补丁信息删掉之后想卸载Office或某些驱动会直接报错。我在给脚本做边界检查时把这两类目录明确列为永久排除以后扩展功能也不会放开它们。5.3 崩溃转储文件的保留策略C:\Windows\Minidump是崩溃转储目录里面是蓝屏或应用崩溃时的内存快照。很多清理工具为了释放空间会全量删除但我建议留一条底线只清理 30 天前的文件。因为当你遇到莫名其妙的程序崩溃Minidump 是唯一能还原崩溃现场的资料。我见过有人把转储全清了结果下一次驱动蓝屏时没有任何线索可查最后只能重装系统。在脚本里这个目录我没有放进默认循环而是单独写了按时间过滤的逻辑$cutoff (Get-Date).AddDays(-30) Get-ChildItem -Path C:\Windows\Minidump -File -ErrorAction SilentlyContinue | Where-Object { $_.LastWriteTime -lt $cutoff } | Remove-Item -Force -ErrorAction SilentlyContinue5.4 Docker 和 WSL 的虚拟磁盘不能直接删现在的开发者机器上 Docker Desktop 非常普及但它有个很隐蔽的问题所有镜像和容器数据都封装在一个巨大的虚拟磁盘文件里通常是docker-desktop-data的 vhdx 文件即使你删了镜像这个文件也不会自动缩小。最直观的现象是docker system df显示镜像占用已经清了但 C 盘空间纹丝不动。我的处理方式是分两步先用docker system prune -a --volumes清除无主镜像和构建缓存再在 Docker Desktop 的设置里使用磁盘清理功能其实就是后端帮你压缩 vhdx。WSL2 的ext4.vhdx也一样不能直接删除要用wsl --shutdown后执行磁盘压缩工具。把这些内容放进脚本里不现实因为需要额外安装工具和环境依赖但我建议至少把这两条命令记下来每个月手动跑一遍对磁盘空间的健康非常有效。5.5 可清理但需要权衡的缓存目录速查表不是所有缓存都适合无脑清理这里给一个速查表方便不同技术栈的读者对照缓存目录所属生态清理方式代价评估%LOCALAPPDATA%\npm-cacheNode.jsnpm cache clean --force低重装依赖时重新下载即可%LOCALAPPDATA%\pip\cachePythonpip cache purge低重装时重新下载%LOCALAPPDATA%\pnpm-cacheNodepnpmpnpm store prune低只清理未被引用的包%USERPROFILE%\.gradle\cachesAndroid/Java手动删除旧版本缓存中重新构建时慢一些%USERPROFILE%\.nuget\packages.NET手动删除不需要的包高VS 下次还原时要重新下载全部依赖%LOCALAPPDATA%\Yarn\CacheNodeyarnyarn cache clean中重新安装依赖时慢docker镜像与构建缓存Dockerdocker system prune -a中镜像重建成本视项目而定WSL2 ext4.vhdxWSLwsl --shutdown 压缩中压缩过程需要时间这个表的价值在于帮你建立代价意识。清理不是把空间腾出来就完事还要考虑下次构建时的重建成本。我的经验是npm、pip 这类包管理缓存可以每个月清理一次重建成本基本可以忽略Gradle 缓存建议只在磁盘告急时清理因为 Android 项目的构建缓存重建确实耗时NuGet 缓存清理前最好确认一下公司内网源的速度否则删完 VS 打开项目的那一刻就会后悔。5.6 我的每月例行维护流程最后分享一下我现在固定的维护节奏每月 1 号凌晨脚本会自动跑一遍把系统临时文件、更新缓存、回收站和常用开发工具缓存全部清一次。每个季度我会手动跑一次 Docker 和 WSL 的压缩命令顺手看一眼 WizTree 里有没有冒出新的占用大户。这套流程跑了半年我的 C 盘可用空间基本稳定在 40% 以上再也没有出现磁盘爆红后手忙脚乱的局面。如果你也受困于开发机磁盘空间我建议不要急着装各种清理软件先花半小时把目录地图摸清楚然后直接拿这篇文章的脚本改一改跑一次看看报告。那种原本以为要一直低空间运行、结果一键清出几十GB的体验确实挺上瘾的。
Windows开发机磁盘爆红自救：PowerShell脚本清理临时文件与缓存
前阵子帮同事处理笔记本C盘爆红的问题他第一反应是卸载软件、删安装包折腾半小时才释放了3GB。我坐在旁边开了一个管理员PowerShell把系统临时文件、Windows更新缓存、回收站和几个开发工具的构建缓存扫了一遍一次性清出41.6GB。同事当场愣住第一句话是这些删了会不会出事这个问题其实正好问到临时文件自动化清理的核心开发者电脑上的临时文件既想放开手删又绝对不想碰个人文档、照片、安装软件。网上那些一键清理工具敢不敢用是一回事清得干不干净是另一回事。后来我把这套思路整理成了脚本陆续在几台开发机和同事电脑上跑过每次都能稳定释放 10GB 以上的空间而且至今没有误删过任何有效数据。这篇文章就把完整的方法、脚本、以及踩过的坑都摊开讲一遍适合那些整天跟微信开发者工具、Chrome DevTools、Node/Python 缓存打交道的开发者特别是 Windows 环境下做前端、客户端或全栈开发的朋友。1. 磁盘告急前的排查开发机的临时文件分布在哪儿想要清理不误伤第一件事是把临时文件的地图画出来。很多人的误区是只盯着桌面的下载文件夹删却忘了真正的空间黑洞全藏在系统目录和应用数据目录里。我按来源把开发机上常见的可清理项分成三类每一类都曾经在实测中清出过大量空间。1.1 系统目录那一摊Temp、更新缓存、回收站这一类是人人都知道但谁都删不干净的部分用户临时目录C:\Users\用户名\AppData\Local\Temp这里几乎什么都有安装包解压残留、编辑器草稿、崩溃转储临时文件长时间不清理能膨胀到 5GB 以上而且因为是按用户隔离的手动翻文件夹非常痛苦。系统临时目录C:\Windows\Temp系统组件和部分驱动程序运行时产生的垃圾通常比用户 Temp 小一些但 1-3GB 很常见。Windows 更新缓存C:\Windows\SoftwareDistribution\Download补丁包下载后的存放点更新安装完其实就用不上了。这台机器上愣是攒了 8GB 的旧补丁包这就是大头之一。回收站很多人以为回收站是空的结果里面躺着几个季度的旧安装包和压缩包。实测回收站冗余文件清出 6GB 以上的情况并不罕见。还有一类容易被忽略的资源管理器缩略图缓存C:\Users\用户名\AppData\Local\Microsoft\Windows\Explorer它专门存文件夹缩略图平时也就几百MB但如果你经常浏览图片素材目录也会悄悄变胖。1.2 开发工具与包管理器真正的大头藏在这里很多开发者的磁盘空间不是被系统吃掉的而是被各种包管理器和构建工具的缓存吃掉的。这一块必须重点说因为系统命令大家多少都接触过但开发工具缓存却很少被纳入常规清理范围npm 缓存AppData\Local\npm-cache每次npm install都会往这里塞压缩包。做过前端项目的人都懂半年不清理三四GB是常态。pip 缓存AppData\Local\pip\cachePython 的下载包缓存装过深度学习相关库的机器上2GB 以上轻轻松松。pnpm 和 Yarn 的缓存pnpm 的全局存储甚至还会做硬链接复用不清理的话体积同样可观。Gradle 的C:\Users\用户名\.gradle\cachesAndroid 或 Java 开发者最熟悉构建缓存的体积经常按 GB 算。VS Code 缓存AppData\Roaming\Code\Cache和CachedData编辑器开久了界面缓存和文件缓存也能堆出一两个GB。这只是默认路径。实际每家项目不同有些公司内部还会把 Maven 库、CocoaPods 镜像等全部指向本地那才是真正的空间杀手。想快速摸清底细最简单的方法是打开 WizTree 或 TreeSize按文件大小排序扫一遍立刻就能看到谁在占地方。我自己的经验是80% 的可用空间都是从 AppData 和用户主目录下的隐藏缓存里释放出来的。1.3 浏览器开发调试与跨端工具容易被忽略的增量开发者的浏览器和普通人的浏览器不是一回事。整天开着 Chrome DevTools 或 Edge 开发者模式调页面的人会积累大量网络缓存、Local Storage 快照和调试日志。最典型的是 Chrome 的缓存目录AppData\Local\Google\Chrome\User Data\Default\Cache如果你习惯在 Network 面板勾选 Disable cache 来调试接口那缓存写入反而会更频繁因为每一轮请求都在重新落盘。这里我要特别提一下微信开发者工具这类基于 Electron/Chromium 的开发工具。很多前端同事每天开着它编译小程序它的本地缓存、编译产物和运行日志都存放在 AppData 下的应用专属目录里日积月累非常可观。我刚接到这个需求时那台电脑上微信开发者工具的缓存目录就有 7GB 多。另一个案例是效率类工具比如 workbuddy 这类会记录对话数据、运行缓存的软件它们的数据目录同样在 AppData 下但里面既有可清理的缓存也有不能动的用户记录。清理这类目录前必须先分清楚二者的边界这也是为什么我认为懂技术的人自己写脚本比无脑一键清理安全得多。2. 为什么我把方案定为脚本白名单清理而不是管家类软件做这个自动化清理项目前我认真对比过三条路线手动清理、第三方清理工具、自己写脚本。只有把各自的代价想清楚你才能明白为什么我最终选了脚本化。先说说为什么不是手动清理。手动清理的痛点很明显临时目录分散在系统十几个位置每次都要挨个去翻而且很多目录默认隐藏普通路径根本看不到。更关键的是手动清理很难做到可重复靠人记性是记不住这么多目录的往往这次清了三个月后又满了又要重新研究一遍。我同事那次手动折腾半小时才释放3GB就是典型的手动清理效率瓶颈。再来说为什么不用各种管家类清理软件。这类工具的优点是界面友好、一键操作但对开发者来说有几个绕不开的顾虑权限边界不透明。很多清理工具会默认开启深度清理扫出来的项目五花八门点一下清理可能连浏览器收藏夹备份、软件配置项都给你清了。广告和捆绑风险。下载渠道稍微不对安装包里就多出几个全家桶这是最劝退的。没法定制。我想保留某些大缓存目录、单独排除某几个路径时这些软件往往做不到精细化操作。脚本化清理的核心优势我总结成三个词可控、可审计、可复用。脚本里每一行删了什么都有记录每次执行完能输出一份清单我今天清了什么、释放了多少空间一目了然。出问题也能回溯。而且脚本拿到任何一台电脑上都能跑不需要重新配置。在设计这套方案时我给自己定了三条硬性原则这也是我在热词里看到清理完成后告知我释放的空间大小这类需求时最想强调的原则一只动可再生缓存绝不碰用户数据。文档、照片、源码工程、安装好的软件一律不在脚本的删除范围内。原则二宁可收敛不可冒进。拿不准的目录先跳过宁可这次少清一点也不要一句话删除把环境搞坏。原则三先计量后删除。每个目录清理前先算大小清理后再算一遍这样最终释放空间不是拍脑袋而是有实打实的数据支撑。这三条原则贯穿了整个脚本的设计。接下来我会把完整实现直接放出来并且把每一段代码的意图讲清楚不是说脚本给你、跑就完事而是让读者能看懂每一条命令在做什么、为什么这么做。3. 完整脚本实现从统计到清理再到输出报告3.1 前置条件与运行策略脚本基于 Windows PowerShell 5.1 编写Windows 10/11 自带不需要额外安装。运行前有几个前置条件必须以管理员身份运行 PowerShell。否则访问C:\Windows\Temp和更新缓存时会遇到权限限制清理不干净。建议先关闭正在运行的开发工具尤其是微信开发者工具、VS Code、Chrome以及 Docker Desktop。这些工具会长期占用自身缓存文件的句柄如果你不关闭它们部分文件会删除失败脚本虽然不会报错但会静默跳过回头还得重跑一次。脚本默认只处理 C 盘。如果你的开发环境把缓存目录放在了 D 盘或 E 盘需要根据第 4 章的说明手动扩展。下面是完整的脚本内容。考虑到可读性我把核心逻辑拆成三块空间计算函数、清理函数、主流程。# 开发者临时文件自动清理脚本 # 适用环境: Windows 10/11, PowerShell 5.1 # 运行要求: 管理员权限 # 设计原则: 只清理明确可再生的缓存/临时文件绝不触碰用户数据 $ErrorActionPreference SilentlyContinue $StartTime Get-Date $Report () # 计算一个目录占用多少空间单位 MB function Get-FolderSizeMB { param([string]$Path) if (-not (Test-Path -LiteralPath $Path)) { return 0 } $bytes (Get-ChildItem -LiteralPath $Path -Force -Recurse -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum -ErrorAction SilentlyContinue).Sum if (-not $bytes) { $bytes 0 } return [math]::Round($bytes / 1MB, 2) } # 清理目录内容并记录释放前后的体积 function Clear-FolderContent { param( [string]$Path, [string]$DisplayName ) if (-not (Test-Path -LiteralPath $Path)) { return } $beforeMB Get-FolderSizeMB $Path # 不足 1MB 的目录直接跳过避免无谓的遍历耗时 if ($beforeMB -lt 1) { return } Get-ChildItem -LiteralPath $Path -Force -ErrorAction SilentlyContinue | Remove-Item -Recurse -Force -ErrorAction SilentlyContinue $afterMB Get-FolderSizeMB $Path $freedMB [math]::Round($beforeMB - $afterMB, 2) if ($freedMB -gt 0) { $script:Report [PSCustomObject]{ 清理项目 $DisplayName 清理前 $beforeMB MB 清理后 $afterMB MB 本次释放 $freedMB MB } Write-Host (完成: {0,-40} 释放 {1} MB -f $DisplayName, $freedMB) -ForegroundColor Green } } # 记录初始可用空间 $drive Get-PSDrive -Name C $freeBefore [math]::Round($drive.Free / 1MB, 2) Write-Host 开始时间: $($StartTime.ToString(yyyy-MM-dd HH:mm:ss)) -ForegroundColor Cyan Write-Host C盘初始可用空间: $freeBefore MB -ForegroundColor Cyan Write-Host ----------------------------------------第一段是基础工具函数。为什么要单独封装计算目录大小因为清理前后都需要统计如果不封装主流程会变得非常臃肿。Get-FolderSizeMB里用了ErrorAction SilentlyContinue这是刻意的——当目录里有正在被占用的文件Get-ChildItem读取某些文件大小会报权限错设置静默后这些单个文件的缺失不会中断整个统计过程最多让数值稍微偏小但方向是对的。Clear-FolderContent里的不足 1MB 跳过是我多次实测后加上的优化。不要小看这个判断Windows 上存在大量 0-0.5MB 的临时目录如果每次都全量遍历再删除几百个目录下来会白白浪费几分钟。小目录跳过既不耽误正事也不影响清理效果。现在看主流程也就是真正执行清理的部分# 临时目录与开发工具缓存 $targets ( { Name 用户临时目录; Path $env:TEMP }, { Name 系统临时目录; Path C:\Windows\Temp }, { Name 网络缓存; Path $env:LOCALAPPDATA\Microsoft\Windows\INetCache }, { Name 资源管理器缩略图; Path $env:LOCALAPPDATA\Microsoft\Windows\Explorer }, { Name Chrome 缓存; Path $env:LOCALAPPDATA\Google\Chrome\User Data\Default\Cache }, { Name npm 缓存; Path $env:LOCALAPPDATA\npm-cache }, { Name pip 缓存; Path $env:LOCALAPPDATA\pip\cache }, { Name pnpm 缓存; Path $env:LOCALAPPDATA\pnpm-cache }, { Name VS Code 缓存; Path $env:APPDATA\Code\Cache }, { Name Gradle 缓存; Path $env:USERPROFILE\.gradle\caches } ) foreach ($t in $targets) { Clear-FolderContent -Path $t.Path -DisplayName $t.Name } # Windows 更新缓存: 需要判断更新服务状态 Write-Host ---------------------------------------- $sdPath C:\Windows\SoftwareDistribution\Download $wuService Get-Service -Name wuauserv -ErrorAction SilentlyContinue if ($wuService.Status -eq Running) { Write-Host Windows 更新服务运行中跳过更新缓存清理可下次重启后手动执行 -ForegroundColor Yellow $script:Report [PSCustomObject]{ 清理项目 Windows 更新缓存 清理前 跳过 清理后 服务占用中 本次释放 - } } else { # 停止更新相关服务删除下载缓存再重新启动服务 Stop-Service -Name wuauserv -Force -ErrorAction SilentlyContinue Stop-Service -Name bits -Force -ErrorAction SilentlyContinue Clear-FolderContent -Path $sdPath -DisplayName Windows 更新缓存 Start-Service -Name wuauserv -ErrorAction SilentlyContinue Start-Service -Name bits -ErrorAction SilentlyContinue Write-Host Windows 更新服务已恢复 -ForegroundColor Cyan } # 回收站: 用 COM 方式读取大小再执行清空 Write-Host ---------------------------------------- $shell New-Object -ComObject Shell.Application $rb $shell.Namespace(10) $rbBytesBefore 0 foreach ($item in $rb.Items()) { if ($item.Size) { $rbBytesBefore $item.Size } } $rbMBBefore [math]::Round($rbBytesBefore / 1MB, 2) if ($rbMBBefore -gt 0) { Clear-RecycleBin -DriveLetter C -Force -ErrorAction SilentlyContinue $script:Report [PSCustomObject]{ 清理项目 回收站 清理前 $rbMBBefore MB 清理后 0 MB 本次释放 $rbMBBefore MB } Write-Host (完成: {0,-40} 释放 {1} MB -f 回收站, $rbMBBefore) -ForegroundColor Green } else { Write-Host 回收站已经是空的跳过 -ForegroundColor DarkGray }主流程分了三大块。第一块是常规缓存目录的遍历清理注意我在$targets表里刻意没有包含.nuget\packages和Yarn缓存。为什么不放因为这两个目录删除后代价不是重新生成这么简单——NuGet 包删除后Visual Studio 下次打开项目会重新还原如果公司内部源不稳定下载过程能把人逼疯Yarn 缓存同理。它们属于可清理但需要谨慎权衡的目录后面第 5 章会专门讲怎么处理这一档。第二块是 Windows 更新缓存的单独处理。这里的逻辑其实是从一次翻车经历里总结出来的最初我直接用 Remove-Item 去删SoftwareDistribution\Download结果删到一半遇到正在被系统更新服务占用的文件系统没有报错但后续 Windows Update 界面出现了异常状态。所以现在的方案是先检查wuauserv服务如果是运行中干脆跳过本次删除等机器空闲再手动清如果服务不在运行就停掉更新服务和 BITS 服务删完再恢复。这样既不会跟系统抢文件也不会留下服务状态异常的后遗症。第三块是回收站。这里用了 Shell.Application 的 COM 接口来获取回收站总大小而不是直接遍历C:\$Recycle.Bin。原因是$Recycle.Bin目录在系统层面有特殊权限直接遍历读取经常拿不到完整数据而 COM 方式是 Windows 自己的接口准确性和稳定性都有保障。脚本最后是收尾统计和报告输出# 最终统计与报告写入 Write-Host ---------------------------------------- $drive Get-PSDrive -Name C $freeAfter [math]::Round($drive.Free / 1MB, 2) $freedTotal [math]::Round($freeAfter - $freeBefore, 2) $elapsed [math]::Round(((Get-Date) - $StartTime).TotalSeconds, 1) Write-Host 清理完成共耗时 $elapsed 秒 -ForegroundColor Cyan Write-Host C盘初始可用空间: $freeBefore MB -ForegroundColor Cyan Write-Host C盘当前可用空间: $freeAfter MB -ForegroundColor Cyan Write-Host (总计释放: {0} MB -f $freedTotal) -ForegroundColor Green # 报告写入桌面文件 $reportPath Join-Path $env:USERPROFILE Desktop\磁盘清理报告_$($StartTime.ToString(yyyyMMdd_HHmm)).txt $Report | Format-Table -AutoSize | Out-String | Set-Content -Path $reportPath Write-Host 详细报告已保存到: $reportPath -ForegroundColor Cyan报告逻辑用了两个关键数据源一个是逐目录记录清理前后体积的$Report数组另一个是整盘剩余空间的前后差值。有人会问既然已经逐项统计了为什么还要整盘差值因为临时目录里还有一部分你没有在清单里但确实被删掉的垃圾比如某些软件自动清理后留下的空目录和占位文件它们不会体现在单项清理里但会让整盘剩余空间发生额外变化。用整盘差值来兜底报告的总释放数字才够真实。每次执行完桌面会生成一份磁盘清理报告_日期时间.txt里面按表格列出每个清理项的释放情况。这也直接满足了清理完成后告知我释放的空间大小的需求而且是更有说服力的逐项明细。3.2 运行效果实测我在一台用了大半年的开发机上跑过这个脚本配置是 512GB SSD平时主要做前端开发和 API 调试。运行前 C 盘只剩 18GB跑完脚本后可用空间到了 59GB一次释放 41GB。其中利润最大的是用户临时目录9.8GB、Chrome 缓存6.2GB、微信开发者工具的应用缓存目录我自己后续追加进去的7GB 多、Windows 更新缓存5.8GB和回收站6.4GB。整个执行过程不到 15 分钟中间没有报错也没有影响任何正在运行的基础服务。4. 定时任务挂载与白名单自定义脚本能手动跑是一回事能自动定期跑才是真正的自动化清理。这一节把排程和自定义配置讲清楚。4.1 用任务计划程序挂载月度清理我的建议是每个月跑一次频率太高的意义不大因为开发工具的缓存重建需要时间频率太低又容易让磁盘再次爆红。在任务计划程序里创建任务的要点如下触发器每月 1 号凌晨 3 点或者每周日早上。操作启动程序填powershell.exe参数填-NoProfile -ExecutionPolicy Bypass -File C:\Scripts\DevDiskCleanup.ps1。勾选使用最高权限运行。这一步非常关键否则脚本无法删除系统临时目录。命令行创建方式也可以这里给一个参考写法schtasks /Create /TN DevDiskCleanup /TR powershell.exe -NoProfile -ExecutionPolicy Bypass -File C:\Scripts\DevDiskCleanup.ps1 /SC MONTHLY /D 1 /ST 03:00 /RU MACHINENAME\你的用户名 /RL HIGHEST /F这里必须提醒一个坑如果用/RU SYSTEM来跑任务PowerShell 里的$env:LOCALAPPDATA和$env:USERPROFILE会指向系统账户的配置目录而不是你日常登录用的用户目录。结果就是脚本跑完报告很漂亮但你的开发工具缓存一个都没清到。所以排程任务一定要指定你自己的用户账号并且勾选使用最高权限运行我在这个坑上栽过一次排查了半天才发现是环境变量解析错了。4.2 将微信开发者工具、workbuddy 等应用缓存纳入清理脚本默认包含的是一批通用目录。开发者的机器各有各的特殊性比如我前面提到的微信开发者工具缓存、workbuddy 的运行缓存与临时文件需要按实际环境追加。追加方法很简单在$targets数组里按相同格式加一行就行{ Name 微信开发者工具缓存; Path $env:APPDATA\Tencent\微信开发者工具 }, { Name workbuddy 运行缓存; Path $env:APPDATA\workbuddy\Cache }但路径不能照抄不同版本的微信开发者工具默认路径可能不同。稳妥做法是先用 WizTree 扫一遍磁盘找到体积最大的几个目录确认属于某个工具的可再生缓存后再写进脚本。这一条同样适用于其他基于 Electron 的开发工具例如钉钉、飞书、Slack 的桌面版它们本质上是 Chromium 套壳缓存目录模式几乎一样。4.3 白名单机制的必要性虽然脚本默认只清理明确可再生的缓存目录但实践中仍有可能遇到一个目录里混着用户数据和缓存的情况。比如 workbuddy 同时存放对话记录、运行缓存与临时文件如果整个目录删掉对话记录就没了。这时候要在清理函数外额外加一层排除判断。我的做法是在Clear-FolderContent函数里增加一个可选参数$ExcludePaths。在删除前先把目录下的子项列表拿到手逐个判断是否命中排除路径命中的就从删除列表里剔除function Clear-FolderContent { param( [string]$Path, [string]$DisplayName, [string[]]$ExcludePaths ) if (-not (Test-Path -LiteralPath $Path)) { return } $beforeMB Get-FolderSizeMB $Path if ($beforeMB -lt 1) { return } Get-ChildItem -LiteralPath $Path -Force -ErrorAction SilentlyContinue | Where-Object { $keep $false foreach ($ex in $ExcludePaths) { if ($_.FullName -like $ex*) { $keep $true; break } } -not $keep } | Remove-Item -Recurse -Force -ErrorAction SilentlyContinue $afterMB Get-FolderSizeMB $Path # ... 后续报告逻辑保持一致 }这个改动让脚本从按目录白名单清理升级为按目录主题清理 文件级排除灵活性高了很多。比如你想清理 workbuddy 的缓存子目录但保留它Data文件夹下的对话记录那就把Data目录加进ExcludePaths。这是我后来在真实环境下迭代出来的因为开发者的应用数据目录往往不是纯缓存一刀切很容易出事。5. 踩坑实录与扩展哪些看似很好删的目录其实很危险这个项目做到现在我踩过不少坑也积累了一些非常有价值的经验。把这些写出来比单纯给脚本更能帮助读者避开雷区。5.1 Windows 更新缓存的正确清理姿势前文已经讲了要停服务再删这里再补充一个细节停止wuauserv和bits服务前最好确认系统当前没有正在下载或安装更新。最简单的方法是在设置里看一眼更新状态如果是正在下载 XX%或正在安装就放弃本次清理。如果不小心在更新过程中强行停止了服务下次开机 Windows Update 可能会重新下载之前的补丁包这倒不是大问题最多浪费点流量但如果你在服务器上做同样的操作就要更加谨慎生产环境优先选择Dism /Online /Cleanup-Image /StartComponentCleanup这类官方工具而不是手动删目录。5.2 组件存储、安装缓存这些高危目录别碰C:\Windows\WinSxS组件存储是 Windows 运维新手最容易盯上的目标因为它动辄 10GB 以上。但这里存放的是系统组件的硬链接和旧版本备份直接删除会让 Windows 更新彻底失效甚至导致系统无法启动。正确做法是用系统自带的磁盘清理工具勾选Windows 更新清理来安全回收。同样的还有C:\Windows\Installer这里记录着已安装软件的补丁信息删掉之后想卸载Office或某些驱动会直接报错。我在给脚本做边界检查时把这两类目录明确列为永久排除以后扩展功能也不会放开它们。5.3 崩溃转储文件的保留策略C:\Windows\Minidump是崩溃转储目录里面是蓝屏或应用崩溃时的内存快照。很多清理工具为了释放空间会全量删除但我建议留一条底线只清理 30 天前的文件。因为当你遇到莫名其妙的程序崩溃Minidump 是唯一能还原崩溃现场的资料。我见过有人把转储全清了结果下一次驱动蓝屏时没有任何线索可查最后只能重装系统。在脚本里这个目录我没有放进默认循环而是单独写了按时间过滤的逻辑$cutoff (Get-Date).AddDays(-30) Get-ChildItem -Path C:\Windows\Minidump -File -ErrorAction SilentlyContinue | Where-Object { $_.LastWriteTime -lt $cutoff } | Remove-Item -Force -ErrorAction SilentlyContinue5.4 Docker 和 WSL 的虚拟磁盘不能直接删现在的开发者机器上 Docker Desktop 非常普及但它有个很隐蔽的问题所有镜像和容器数据都封装在一个巨大的虚拟磁盘文件里通常是docker-desktop-data的 vhdx 文件即使你删了镜像这个文件也不会自动缩小。最直观的现象是docker system df显示镜像占用已经清了但 C 盘空间纹丝不动。我的处理方式是分两步先用docker system prune -a --volumes清除无主镜像和构建缓存再在 Docker Desktop 的设置里使用磁盘清理功能其实就是后端帮你压缩 vhdx。WSL2 的ext4.vhdx也一样不能直接删除要用wsl --shutdown后执行磁盘压缩工具。把这些内容放进脚本里不现实因为需要额外安装工具和环境依赖但我建议至少把这两条命令记下来每个月手动跑一遍对磁盘空间的健康非常有效。5.5 可清理但需要权衡的缓存目录速查表不是所有缓存都适合无脑清理这里给一个速查表方便不同技术栈的读者对照缓存目录所属生态清理方式代价评估%LOCALAPPDATA%\npm-cacheNode.jsnpm cache clean --force低重装依赖时重新下载即可%LOCALAPPDATA%\pip\cachePythonpip cache purge低重装时重新下载%LOCALAPPDATA%\pnpm-cacheNodepnpmpnpm store prune低只清理未被引用的包%USERPROFILE%\.gradle\cachesAndroid/Java手动删除旧版本缓存中重新构建时慢一些%USERPROFILE%\.nuget\packages.NET手动删除不需要的包高VS 下次还原时要重新下载全部依赖%LOCALAPPDATA%\Yarn\CacheNodeyarnyarn cache clean中重新安装依赖时慢docker镜像与构建缓存Dockerdocker system prune -a中镜像重建成本视项目而定WSL2 ext4.vhdxWSLwsl --shutdown 压缩中压缩过程需要时间这个表的价值在于帮你建立代价意识。清理不是把空间腾出来就完事还要考虑下次构建时的重建成本。我的经验是npm、pip 这类包管理缓存可以每个月清理一次重建成本基本可以忽略Gradle 缓存建议只在磁盘告急时清理因为 Android 项目的构建缓存重建确实耗时NuGet 缓存清理前最好确认一下公司内网源的速度否则删完 VS 打开项目的那一刻就会后悔。5.6 我的每月例行维护流程最后分享一下我现在固定的维护节奏每月 1 号凌晨脚本会自动跑一遍把系统临时文件、更新缓存、回收站和常用开发工具缓存全部清一次。每个季度我会手动跑一次 Docker 和 WSL 的压缩命令顺手看一眼 WizTree 里有没有冒出新的占用大户。这套流程跑了半年我的 C 盘可用空间基本稳定在 40% 以上再也没有出现磁盘爆红后手忙脚乱的局面。如果你也受困于开发机磁盘空间我建议不要急着装各种清理软件先花半小时把目录地图摸清楚然后直接拿这篇文章的脚本改一改跑一次看看报告。那种原本以为要一直低空间运行、结果一键清出几十GB的体验确实挺上瘾的。
