干我们这行的电脑上最不缺的就是临时文件。项目跑完日志堆了一地编译一次中间产物比源码还大IDE开两天索引缓存直接把磁盘塞满。平时懒得管等C盘飘红、磁盘空间告急才知道“临时文件自动化清理”这五个字有多值钱。这篇内容适合所有经常被磁盘空间困扰的开发者——不管你是天天打交道的Windows用户还是习惯Linux服务器的后端我尽量把思路、代码、坑都写清楚你照着改就能用。主题就一个写脚本把临时文件管起来安全删删完告诉你释放了多少空间。1. 临时文件为什么越攒越多清理为什么必须自动化1.1 开发者设备上的临时文件从哪来先盘一下家底。开发者电脑上的临时文件来源比你想的多得多系统临时目录Windows的C:\Users\用户名\AppData\Local\TempLinux的/tmp和/var/tmpmacOS的$TMPDIR这里面既有安装包解压残留也有程序崩溃时留下的dump文件。Windows 更新缓存C:\Windows\SoftwareDistribution\Download这个目录专门存放Windows更新下载的安装包系统更新装完以后里面的文件基本就是纯废物却能轻松占用几个GB。软件日志各种应用的logs目录尤其是开发工具一天能写几十MB日志。Debug级别跑起来日志文件增长速度快到你怀疑人生。应用缓存浏览器的CacheNode的npm cachePython的pip cacheGo的go build缓存Git的.git对象残留还有Electron系应用的Cache目录这些都是“看起来没用但程序就是不开源删”的数据。回收站遗留你以为删掉的文件就消失了没有它们只是躺在回收站里继续占着磁盘空间。我见过同事的回收站里躺着80GB的虚拟机镜像。构建产物与依赖缓存node_modules里的.cache、target、dist、build这些目录清理的时候要小心但它们确实会占用大量空间。每个来源看起来都不起眼一旦叠加起来就很可观。我之前帮同事清一台开发机光是AppData\Local\Temp就找到12GB的Visual Studio编译缓存加上npm和pip的缓存一次性释放了接近30GB。1.2 为什么要写脚本而不是手工清理有人会问Windows不是自带“磁盘清理”工具吗手动点几下不就行了问题是手工清理有三个绕不开的痛点第一你永远记不住上次什么时候清的。临时文件是持续产生的今天清完明天项目一跑又涨回来。磁盘清理工具属于“出了问题才想起来用”的方案等到想起来的时候C盘早就飘红了。第二手动清理容易漏。系统自带的磁盘清理只覆盖部分目录像pip cache、npm cache、IDE索引、WSL虚拟磁盘里的临时文件它根本不会管。你得挨个目录去翻翻漏一个就等于没清干净。第三手动清理容易误删。很多开发者的“清理”就是打开C盘一顿删删到什么不该删的第二天发现项目启动不了那才叫欲哭无泪。脚本就不一样规则可以提前定死什么能删、什么必须留写清楚之后交给机器执行比人肉判断靠谱得多。我们写自动化清理脚本解决的就是这三个问题定时跑、范围全、规则严。脚本跑完还能自己统计释放了多少空间不用你猜。2. 自动化清理的设计思路与选型2.1 清理范围划定哪些能删、哪些绝不能碰写脚本的第一步不是写代码而是画红线。我自己的原则是宁可漏删不可误删。开发机上的文档、照片、源码、安装软件这些都是真金白银清错了代价太高。需要划进清理范围的总结起来就几类清理对象典型路径备注系统临时文件Windows%TEMP%Linux/tmp、/var/tmp删除时可跳过正在被占用的文件Windows更新缓存C:\Windows\SoftwareDistribution\Download删除前建议先停掉Windows Update服务软件日志应用logs目录注意日志轮转按修改时间删超过30天再清应用缓存npm cache、pip cache、go build缓存用工具自带命令清别直接删整个目录回收站冗余文件Windows回收站、Linux~/.local/share/Trash直接清空无需保留构建残留缓存node_modules\.cache、.gradle、.m2仓库旧版本保留当前项目依赖只清过期缓存Electron类应用缓存workbuddy、VS Code等工具的缓存目录按具体应用目录定向处理绝不能碰的个人文档目录、照片库、数据库数据目录、虚拟机磁盘镜像、正在运行的Docker容器数据卷、.git目录本身。这些东西一旦删除轻则项目回归重则数据全无。我的方案里所有删除范围都严格限定在“缓存类目录”和“临时目录”绝不递归扫描用户文档、桌面、图片这些位置。2.2 脚本语言与运行方式的选择清理脚本用什么语言主要看你的使用场景Windows 主力机PowerShell 是首选。它调用Windows原生API方便可以完美处理权限问题、文件属性和回收站操作。不要用批处理写起来绕处理长路径和特殊字符会想死。如果你机器上有Git用Git Bash执行Bash脚本也行但权限处理和路径格式要额外处理。Linux/macOS 服务器或开发机Bash 一把梭systemd timer cron 定期执行。Bash 处理文件循环、查找、删除都很顺手脚本依赖少任何发行版都能跑。跨平台统一管理如果你想在Windows和Linux上共用一套逻辑可以用Python配pathlib处理路径但要记得处理权限、文件锁定等平台差异工程量会大一些。我个人的习惯是Windows上做用户态清理用PowerShellLinux服务器上用Bash各司其职不强行统一。理由很简单——每个平台的临时文件机制差异太大强行写一套跨平台脚本最后的结果往往是两边的坑都踩一遍。2.3 白名单与黑名单机制设计清理脚本的规则设计核心是三层过滤第一层目录白名单。只允许脚本扫描预设的几个目录不在白名单里的目录一律不碰。比如Windows上只扫描$env:TEMP、SoftwareDistribution\Download、C:\Windows\Prefetch这些明确是缓存/临时性质的位置。这个白名单可以有效防止脚本路径写错时把用户目录给清空。第二层文件黑名单。对于某些目录虽然整体可以清理但里面可能有需要保留的文件。比如缓存目录里的debug.log你可能正在排查问题刚写好的patch文件也许还在用。我会在脚本里记录一个“最近7天修改过”的例外列表这个列表里的文件跳过删除。第三层预演模式Dry-Run。所有脚本都必须支持一个-DryRun参数只列出要删的文件和释放空间估算不实际删除。这个模式太重要了我第一次写清理脚本时直接全量跑结果把刚下载还没安装的安装包全删了心疼了好一阵。预演模式跑一遍确认无误再实际执行是排查误删风险的底线。3. 核心清理逻辑与代码实现3.1 Windows 平台PowerShell 自动化清理脚本Windows端我写过一个比较完整的PowerShell脚本核心思路是先按目录清理每删一个文件就把大小记下来最后统计总释放空间。# Invoke-Cleanup.ps1 param( [switch]$DryRun, [int]$DaysOld 30 ) $startFree (Get-PSDrive C).Free $totalFreed 0 $skipped () function Remove-OldFile { param( [string]$Path, [int]$DaysOld, [bool]$DryRun ) if (-not (Test-Path $Path)) { return } Get-ChildItem -Path $Path -Recurse -Force -ErrorAction SilentlyContinue | Where-Object { -not $_.PSIsContainer -and $_.LastWriteTime -lt (Get-Date).AddDays(-$DaysOld) } | ForEach-Object { $size $_.Length if ($DryRun) { Write-Host [DryRun] 将删除: $($_.FullName) ($([math]::Round($size/1MB,2)) MB) } else { try { Remove-Item -LiteralPath $_.FullName -Force -ErrorAction Stop $script:totalFreed $size } catch { $script:skipped $_.FullName } } } } # 1. 用户临时目录 Remove-OldFile -Path $env:TEMP -DaysOld $DaysOld -DryRun $DryRun # 2. Windows 更新缓存需要管理员权限 $updateCache C:\Windows\SoftwareDistribution\Download if (Test-Path $updateCache) { Remove-OldFile -Path $updateCache -DaysOld $DaysOld -DryRun $DryRun } # 3. 清空回收站 if (-not $DryRun) { try { Clear-RecycleBin -Force -ErrorAction SilentlyContinue Write-Host 回收站已清空 } catch { Write-Host 回收站清理失败: $($_.Exception.Message) } } # 4. 统计结果 $endFree (Get-PSDrive C).Free $diff [math]::Round(($endFree - $startFree) / 1MB, 2) Write-Host 清理报告 Write-Host 本次清理释放空间: $($diff) MB Write-Host 跳过占用文件数量: $($skipped.Count)这个脚本有几个细节值得说道说道-ErrorAction SilentlyContinue配合-ErrorAction Stop结合使用是为了让单个文件被占用时不影响整体执行。不被占用的文件正常删被占用的跳过最后报告里有记录。回收站用Clear-RecycleBin -Force比手动点击“清空回收站”靠谱不会弹确认框。Windows更新缓存目录删除时如果更新服务正在运行部分文件会被锁定。实测中我遇到过删除到一半报“正在被另一个进程使用”的情况归属到skipped数组做个标记就好不影响大局。彻底清理可以配合sconfig或服务停止但作为日常清理不需要每次都做那么重的操作。注意Windows脚本涉及C:\Windows\SoftwareDistribution时需要管理员权限建议右键“以管理员身份运行”。不想每次右键的话可以给脚本创建一个快捷方式勾选“以管理员身份运行”或者用任务计划程序配置最高的权限运行。3.2 Linux/macOS 平台Bash 自动化清理脚本Linux端的清理逻辑和Windows大同小异但有几个平台特有的点/tmp目录有sticky bit删除时不能删目录本身要删目录里的内容日志清理要优先用logrotate的产物npm、pip、go这些工具缓存有各自的清理命令。#!/usr/bin/env bash # cleanup-temp.sh set -uo pipefail DRY_RUN${1:-} START_FREE$(df -P / | awk NR2 {print $4}) TOTAL_FREED0 DAYS_OLD30 log() { echo [$(date %Y-%m-%d %H:%M:%S)] $* } safe_remove() { local path$1 local days$2 if [ ! -e $path ]; then return 0 fi while IFS read -r -d file; do local size size$(stat -c %s $file 2/dev/null || echo 0) if [ $DRY_RUN dry-run ]; then log [dry-run] 将删除: $file ($((size / 1024 / 1024)) MB) else if rm -f $file 2/dev/null; then TOTAL_FREED$((TOTAL_FREED size)) else log 跳过被占用文件: $file fi fi done (find $path -type f -mtime $days -print0 2/dev/null) } # 1. 清理系统临时目录内容 safe_remove /tmp $DAYS_OLD safe_remove /var/tmp $DAYS_OLD # 2. 清理用户缓存目录 safe_remove ${HOME}/.cache $DAYS_OLD # 3. 清理应用缓存 npm cache clean --force 2/dev/null log npm 缓存已清理 pip cache purge 2/dev/null log pip 缓存已清理 go clean -cache 2/dev/null log go 构建缓存已清理 # 4. 清理 journal 日志保留最近 100MB journalctl --vacuum-size100M 2/dev/null log journal 日志已收缩到 100MB 以内 # 5. 清理回收站 rm -rf ${HOME}/.local/share/Trash/* 2/dev/null log 回收站已清理 END_FREE$(df -P / | awk NR2 {print $4}) DIFF$(( (END_FREE - START_FREE) / 1024 )) log 清理报告 log 本次清理释放空间: ${DIFF} MB这里面有几个容易踩的坑set -e千万慎用。清理脚本里很多命令本来就是“找得到就删找不到就算了”如果开了set -e遇到某个目录不存在直接退出后面的逻辑全废了。我用的set -uo pipefail不启停错误就退出配合命令内部的|| true或2/dev/null来兜底。find ... -mtime 30的意思是“修改时间在30天之前的”。这个参数在你需要调整清理周期时很有用但要注意日志文件如果一直在被写入mtime会一直更新也就是说“正在运行的进程写的日志能一直躲过30天规则”这其实是好事避免删除正在写入的文件。journalctl --vacuum-size100M是清理systemd日志的专用接口。直接删/var/log/journal目录下的文件容易出问题但用日志系统自己的接口先收缩大小再让journald重启后自动生效就稳妥得多。3.3 workbuddy 等应用缓存与日志的定向清理除了系统层面的清理开发者机器上真正占用空间的往往是应用自己的缓存目录。就拿热词里提到的workbuddy来说这类工具一般会在用户目录下存放对话记录、运行缓存和临时文件体积动辄几个GB。关键是这些目录往往不在系统临时目录里常规清理根本扫不到。我的做法是给脚本增加一个“定向清理”阶段专门扫描已知应用的缓存目录# 定向清理Electron/Tauri 等应用的用户数据缓存目录 function Clear-AppCache { param( [string]$AppPath, [bool]$DryRun ) if (Test-Path $AppPath) { Write-Host 发现应用缓存目录: $AppPath Remove-OldFile -Path $AppPath -DaysOld $DaysOld -DryRun $DryRun } } $appDirs ( $env:APPDATA\workbuddy\Cache, $env:LOCALAPPDATA\workbuddy\Cache, $env:LOCALAPPDATA\workbuddy\Code Cache, $env:LOCALAPPDATA\Programs\WorkBuddy\Cache, $env:APPDATA\Code\Cache, # VS Code $env:APPDATA\Code\CachedData ) foreach ($dir in $appDirs) { Clear-AppCache -AppPath $dir -DryRun $DryRun }这里有两点要特别注意第一不能整个目录直接删。像workbuddy的目录里除了缓存还可能有用户配置、会话记录之类的数据直接删根目录等于把配置也丢了。所以上面的代码只进到Cache、Code Cache这类明确是缓存性质的子目录保留Config、Local Storage等数据目录不动。第二有些缓存目录的文件本来是分布式存储的比如 SQLite 数据库的分片。直接删文件可能导致应用读不到历史会话。稳妥的做法是只删除超过30天未被修改的文件——还是配合那个-DaysOld 30的开关宁少勿滥。如果应用自身带“清理缓存”按钮我优先推荐先用手动功能脚本只做兜底。3.4 空间释放统计与报告所有脚本清理完成后最有感知的反馈就是“到底释放了多少空间”。这里有两种统计维度各有用途维度一系统整体空间变化。清理前后各查一次磁盘总剩余空间相减得到差值。Windows用Get-PSDrive CLinux用df -P /。这个数字最直观但会受到程序并发写入的干扰——清理过程中如果其他进程在写磁盘结果会偏小如果有大文件刚好在清理时被删除结果又会偏大。作为“报告给用户看的数字”完全够用。维度二实际累积的文件大小。每删一个文件就把length累加到一个变量里。这个数字更准确能告诉你脚本到底“处理了多少数据”。我在两个脚本里都加了TOTAL_FREED或$totalFreed变量就是为了保留这个信息。我实际跑完一份报告大概长这样 清理报告 本次清理释放空间: 1836.42 MB 跳过占用文件数量: 17 预热报告: 已删除临时文件 2418 个总大小 1836.42 MB报告放在脚本最后也可以结合计划任务在清理完成后把报告输出到日志文件。Windows的计划任务写法不在这里展开但Linux端如果你用cron只需一行0 3 * * 6 /home/user/scripts/cleanup-temp.sh /home/user/logs/cleanup.log 21每周六凌晨3点跑一次日志沉淀下来慢慢你就能看到自己设备的临时文件增长规律了。4. 验证机制与常见问题排查实录4.1 清理结果怎么验证脚本跑完不代表任务结束验证是必须的。我的习惯是验证三件事第一文件数变化。清理后在临时目录里再数一遍文件数和总大小确认清理生效。Windows可以用系统属性看目录大小Linux用du -sh /tmp如果大小明显下降说明清理真的干了活。反之如果大小没变说明你设置的DaysOld参数太保守或者文件全被占用。第二系统与应用的功能性。清理完之后至少要让工作流跑一遍。我是这么验证的打开IDE编译一次项目启动几个常用程序跑一次日常脚本。如果程序能正常启动、项目能正常编译、日志里不报错基本上说明没有误删关键文件。清理脚本最大的风险不是“删不干净”而是“删过头”所以功能验证步骤不能省。第三空间数值对账。清理报告里显示的“释放空间”和系统实际剩余空间变化两者允许有误差但误差应该在几百MB以内。如果报告说释放了5GB实际剩余空间却只多了1GB那说明清理过程中有进程重新生成了大量缓存或者你的脚本统计逻辑有问题需要回去查。4.2 常见坑与排查实录结合我自己的踩坑经历整理几个高频问题问题现象可能原因解决方案脚本提示“拒绝访问”没有管理员权限或目标文件是系统文件右键以管理员身份运行对单个文件加入跳过列表删除到一半报“正在使用”文件被正在运行的进程锁定记录到跳过列表不阻塞整体执行下次在应用退出后运行PowerShell提示“禁止运行脚本”系统执行策略默认限制脚本运行用Set-ExecutionPolicy RemoteSigned -Scope CurrentUser放开当前用户权限清理后软件重新生成缓存应用缓存目录本身就是应用运行时必需的调整策略将当前正在使用的应用目录从清理范围中排除只清理过期缓存Linux清理/tmp后应用变慢/tmp里有应用依赖的临时文件调整DAYS_OLD为7只删除“一周没动过”的文件Windows更新缓存删不掉Windows Update服务还在运行先net stop wuauserv清理完再net start wuauserv硬盘剩余空间没变化回收站未清理或删除的文件还没触发磁盘整理清空回收站检查是否有其他进程占用文件必要时重启再查看误删了刚下载的安装包手工清理时没注意修改时间所有新增删除规则必须带“按修改时间过滤”刚下载的文件mtime是今天就不会被-DaysOld 30扫到4.3 防止误删与回滚方案最后说一个很多人不重视但我觉得极其重要的事任何自动化清理都必须有后悔药。我常用的回滚方案是在Remove-Item之前先对删除的文件做一次“软删除”——把文件移动到一个备份目录而不是直接删除。虽然会占用一部分临时空间但对于重要度比较高的工作机心理踏实很多。PowerShell里的做法是把Remove-Item换成Move-Item到回收站或备份目录Linux下则是mv到一个.trash隐藏目录。比如# 软删除方案移动到备份目录定期自动清空备份目录 $backupRoot C:\CleanupBackup Move-Item -LiteralPath $file.FullName -Destination $backupRoot -Force这个方案适合第一次跑脚本、对规则还不够信任的阶段。等脚本稳定了确认从没误删过再改成直接Remove-Item也不迟。另外每个清理脚本都必须支持-DryRun或dry-run参数这是底线。我一直把预演模式当成“安全开关”任何规则修改之后都先在预演模式跑一次看看将要删除的文件列表里有没有不该删的东西然后再正式执行。5. 结合个人经验的一点建议写清理脚本这件事技术上不算难难的是对设备和数据有敬畏心。我在实际维护这套脚本的过程中最大的体会是别追求“最全清理”要追求“稳定可重复”。你真正需要的是一个每周都能跑、从不误删、跑完能告诉你结果的机制而不是一次性能清出80GB但哪天不小心把配置清掉的定时炸弹。刚开始可以从最简单的单个目录做起比如只清Temp目录加上-DaysOld 7参数跑两周看效果再慢慢扩展清理范围。每新增一个清理目录都要先问自己一句这个目录里的数据删了我确信不会影响任何正在进行的开发工作吗如果有一丝犹豫就先加白名单再用预演模式验证然后才放开实际删除。脚本跑顺了以后可以给它加个定时任务Windows用任务计划程序Linux用cron或systemd timer再配一份简单的日志输出就能做到“无感清理”。等哪一天磁盘告急的时候你翻出日志来看发现脚本已经默默维护这片战场很久了你会习惯这种感觉。