这次我们不聊算法也不聊模型部署直接聊一个每个开发者都会遇到的事磁盘满了。一开始可能是 C 盘飘红后来可能是 /home 分区报警再往后是 Docker 镜像把磁盘吃到连编译都不想启动。很多人第一反应是找“清理软件”结果发现满网都是下载按钮比清理按钮还明显的全家桶工具。我的建议是先把第三方清理工具放一边用系统自带的命令和脚本自己搭一套“一键清理”流程。这套方案能覆盖 Windows 和 Linux能看清楚每个被删文件的来源也能在误删之后快速定位问题。这篇文章会围绕一条主线展开什么样的文件可以安全清理怎么把平时零散的清理命令收敛成一个可直接执行的脚本以及清理之后如何验证效果、如何避免再次被日志和缓存塞满。如果你已经对重复的“磁盘空间不足”提示感到头疼可以把这套方法当成一个长期可用的运维习惯而不是每次用完就忘的一次性操作。1. 核心能力速览很多“磁盘清理工具”的卖点是界面好看、按钮大但底层做的事情无非就是删除临时文件、清空回收站、清理缓存。自己搭一套脚本方案优势不在于功能数量而在于可解释和可控。下面是这套方案的速览能力项说明适用系统Windows 10/11、Windows Server、主流 Linux 发行版核心功能临时目录清理、回收站清理、日志清理、开发缓存清理、包管理器缓存清理硬件门槛无特殊要求脚本命令本身不依赖 GPU 或高性能 CPU启动方式手动执行脚本、Windows 任务计划程序定时执行、Linux crontab 定时执行安全控制支持“先列出后删除”默认不碰个人文档和应用配置可追溯性每次清理输出日志记录删除路径和释放空间扩展能力可以按项目目录定制清理规则可以接入监控告警适用场景开发机、测试服务器、CI 构建机、长期运行的下载机这套方案的目标不是“把所有文件都删到最小”而是把磁盘空间分为“可安全释放”“有风险”“不可动”三类然后只处理第一类。这样做的好处是即使清理逻辑出现误判问题范围也是可控的。2. 适用场景与使用边界2.1 这套方法适合谁先说实话这不是一个 GUI 应用而是一组命令和脚本思路。适合下面几类人开发者的个人电脑项目编译产物、node_modules、Python 缓存、IDE 索引文件会占用大量空间手动清理费时间。测试服务器和 Jenkins 构建机每次构建都会产生新产物旧产物不清就会把磁盘堵死。运行监控脚本的临时目录比如 /tmp 被频繁写入或者 Windows 的 %TEMP% 出现大量文件。写文章、传文件、做素材整理的内容创作者视频草稿、导出中间文件、浏览器缓存定期清一次能省很多事。2.2 不适合什么场景生产数据库服务器不要用通用清理脚本去删数据库日志文件日志有独立的管理策略。生产环境 Web 服务目录不要直接 rm 正在被进程持有的日志文件会导致句柄泄漏或需要重启服务。没有备份习惯的电脑如果硬盘里有多年未整理的照片、文档先备份不要靠清理脚本来“替你决定”哪些文件重要。被勒索病毒或其他恶意程序影响的机器磁盘空间异常减小可能不是因为缓存而是因为加密文件或挖矿进程这时候先排查安全问题别急着清理。2.3 使用边界任何时候都不要写“删除用户目录下所有文件”这类极端的规则。即便是看起来无害的缓存目录也可能保存着某个应用未保存的恢复文件。正确做法是限定路径、限定文件后缀、限定文件时间并且保留删除日志。涉及到剪贴板里可能出现的人脸、证件、聊天记录等隐私截图清理时要特别小心这类文件万一被误删又没备份恢复成本很高。3. 环境准备与前置条件搭建这套清理方案不需要安装额外运行环境只用到系统自带的 Shell 和基础命令。3.1 Windows 环境系统版本Windows 10 或 Windows 11。终端PowerShell 5.1 或 PowerShell 7建议以管理员身份运行部分命令。需要关注的目录%TEMP% 和 %LOCALAPPDATA%\TempC:\Windows\TempC:\Windows\SoftwareDistribution\DownloadC:\Users用户名\AppData\Local\CrashDumpsC:\Users用户名\AppData\Local\Microsoft\Windows\ExplorerWindows 下面不要直接删除 C:\Windows\Temp 里所有文件有些系统服务正在使用会出现文件占用报错这是正常的可以跳过无法删除的部分。3.2 Linux 环境系统版本Ubuntu、Debian、CentOS、Rocky Linux 等主流发行版均可。需要的基础命令du、find、rm、journalctl。如果没有 du 和 find说明系统太精简先安装 coreutils。需要关注的目录/tmp/var/tmp~/.cache/var/log/var/cache/apt 或 /var/cache/dnf在动手清理前先摸清空间占用分布。用下面命令看一眼哪些目录最大# 查看根目录下各一级目录占用 sudo du -xhd1 / | sort -hr | head -20 # 查看用户主目录下占用x 表示不跨文件系统 du -sh ~/* ~/.[!.]* 2/dev/null | sort -hr | head -20如果系统里有 ncdu用 ncdu 会更直观但这不是必须安装的步骤。# 交互式查看磁盘占用可用方向键浏览d 键删除当前项谨慎使用 ncdu /3.3 清理前一定要做的事清理前要做三件基础工作关闭正在运行的软件浏览器、IDE、容器、数据库这类会持续写缓存的服务先停掉避免删除正在使用的文件。备份重要数据至少要备份数据库目录和项目源码目录。确认当前磁盘剩余空间清理后能马上对比结果。# 查看当前磁盘空间 df -h # 查看当前目录下各子目录占用 du -sh * 2/dev/null | sort -hr | head -20如果磁盘剩余空间在 5% 以下先不要试图“精确分析”直接先清一轮最安全的缓存目录释放空间再回来做细节排查。4. 清理命令梳理与一键脚本搭建这里把清理流程拆成三个层级系统层临时文件、应用缓存与日志、开发项目产物。每一层都给出可复制命令最后合并成一键脚本。4.1 Windows 系统层临时文件清理先看最基础的部分临时目录和回收站。# 查看当前用户的临时目录大小 $tempPath $env:TEMP Get-ChildItem -Path $tempPath -Recurse -Force -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum | Select-Object -ExpandProperty Sum # 清理用户临时目录中超过 1 天未修改的文件 Get-ChildItem -Path $env:TEMP -Recurse -Force -ErrorAction SilentlyContinue | Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-1) } | Remove-Item -Recurse -Force -ErrorAction SilentlyContinue说明一下文件被占用时Remove-Item 会报错这里加 -ErrorAction SilentlyContinue 是为了跳过而不是中断脚本。如果你希望日志记录把报错输出到文件Get-ChildItem -Path $env:TEMP -Recurse -Force -ErrorAction SilentlyContinue | Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-1) } | Remove-Item -Recurse -Force -ErrorAction SilentlyContinue 2 C:\Temp\cleanup_error.logWindows 更新缓存经常占用很大空间但对普通用户来说已经安装完成的更新缓存是可以清理的# 清理 Windows 更新下载缓存需要管理员权限 Stop-Service -Name wuauserv -Force Remove-Item -Path C:\Windows\SoftwareDistribution\Download\* -Recurse -Force -ErrorAction SilentlyContinue Start-Service -Name wuauserv注意清理 Windows 更新缓存前必须停掉 Windows Update 服务否则文件占用会导致删除不完整。清理完立刻重启服务避免系统状态异常。4.2 Linux 系统层临时文件清理Linux 下最简单的对象是 /tmp 和 /var/tmp但清理规则要写成“删除超过 N 天未修改的文件”不要无差别删除所有内容。有些桌面环境会在 /tmp 下存放当前会话的 socket 或锁文件这类文件即使超过时间也不应该随便删因此脚本需要做例外处理。# 查看 /tmp 占用 sudo du -sh /tmp # 删除 3 天前修改的文件路径限定在 /tmp 下的独立子目录 find /tmp -maxdepth 2 -type f -mtime 3 -delete 2/dev/null find /tmp -maxdepth 2 -type d -empty -delete 2/dev/null这样写是为了避免碰到正在使用的套接字文件。深度限定在 2 层以内防止把某些应用放在 /tmp 下的深层状态目录清空。系统日志的清理是 Linux 清理的重点因为 journald 日志会持续增长# 查看系统日志占用 journalctl --disk-usage # 只保留最近 7 天的日志并设置总大小上限为 500M journalctl --vacuum-time7d journalctl --vacuum-size500M也可以直接修改 journald 配置让日志上限长期生效# 编辑 /etc/systemd/journald.conf # 设置 SystemMaxUse500M sudo sed -i s/#SystemMaxUse/SystemMaxUse500M/ /etc/systemd/journald.conf sudo systemctl restart systemd-journald包管理器缓存是另一个大块。Ubuntu/Debian 用 aptCentOS/Rocky 用 dnf# Ubuntu / Debian sudo apt clean sudo apt autoremove --purge -y # CentOS / Rocky / Fedora sudo dnf clean all sudo dnf autoremove -yapt clean 会删除 /var/cache/apt/archives 下的安装包缓存不会影响已安装软件。apt autoremove 会移除不再依赖的库但如果你不确定某个包是否还有用可以先执行 apt --dry-run autoremove 看一下列表。4.3 开发环境缓存清理这一节最能让开发者直观感受到空间释放。一套项目如果前后端合在一起node_modules、虚拟环境、编译中间文件轻轻松松超过 10GB。Python 缓存.pyc文件和__pycache__目录可以直接删除Python 会自动重新生成字节码# 删除当前目录树中所有 Python 缓存目录指定项目根目录执行 find /path/to/project -type d -name __pycache__ -prune -exec rm -rf {} npm 缓存可以安全清理但注意清理后重新安装依赖会变慢# 清理 npm 整个缓存目录 npm cache clean --force # 或者直接查看并删除缓存目录 npm config get cache rm -rf ~/.npm/_cacachepip 的缓存也能清理# 清理 pip 下载缓存 pip cache purgeMaven 的本地仓库缓存通常不需要全删但可以删除.lastUpdated后缀的下载失败残留文件# 删除 Maven 下载失败的残留标记文件不会影响正确下载的依赖 find ~/.m2/repository -name *.lastUpdated -deleteGo 的模块缓存可以查看大小后按需清理# 查看 Go 模块缓存大小 go clean -modcachego clean -modcache 会把整个模块缓存删掉再次构建时需要重新下载。如果项目依赖很大建议先确认是不是真的需要释放空间。4.4 汇总成 Windows 一键清理脚本把上面 Windows 的命令整理成脚本保存为 cleanup.ps1。运行前建议先用 -WhatIf 参数做一次模拟执行确认清理范围。# cleanup_demo.ps1 # 使用示例 # powershell -ExecutionPolicy Bypass -File .\cleanup_demo.ps1 -WhatIf param( [switch]$WhatIf ) $ErrorActionPreference SilentlyContinue $logPath C:\Temp\disk_cleanup.log $tempPaths ( $env:TEMP, $env:LOCALAPPDATA\CrashDumps, $env:WINDIR\Temp ) Start-Transcript -Path $logPath -Append foreach ($path in $tempPaths) { if (Test-Path $path) { Get-ChildItem -Path $path -Recurse -Force | Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-1) } | Remove-Item -Recurse -Force -WhatIf:$WhatIf } } Stop-Transcript在 PowerShell 里可以这样执行模拟Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process .\cleanup_demo.ps1 -WhatIf当输出里列出的文件都是临时目录内的缓存时再移除 -WhatIf 参数正式执行。因为 Windows 某些路径受系统保护建议用管理员身份运行。4.5 汇总成 Linux 一键清理脚本Linux 脚本写成一个 bash 文件内置日志输出和异常处理。#!/bin/bash # cleanup_demo.sh # 适用于 Ubuntu/Debian 系使用前先执行 bash -x 观察实际行为 LOG_FILE/var/log/disk_cleanup.log DAYS_OLD3 THRESHOLD_SIZE500M log() { echo $(date %Y-%m-%d %H:%M:%S) $1 | sudo tee -a $LOG_FILE } cd /tmp log 开始清理临时文件 find /tmp -maxdepth 2 -type f -mtime ${DAYS_OLD} -delete 2/dev/null find /tmp -maxdepth 2 -type d -empty -delete 2/dev/null log 开始清理用户缓存 find /home -maxdepth 3 -type d -name *.cache -mtime ${DAYS_OLD} -prune -exec rm -rf {} \; 2/dev/null log 开始清理系统日志 journalctl --vacuum-size${THRESHOLD_SIZE} 2/dev/null log 开始清理包管理器缓存 apt clean 2/dev/null apt autoremove --purge -y 2/dev/null log 清理完成注意脚本里写find /home -maxdepth 3 -type d -name *.cache -mtime ...的目的是清理用户家目录下过期的.cache子目录但在正式环境中不建议执行这种偏“激进”的规则。更稳妥的做法是先在 /home 下列出 Cache 目录确认路径后单独清理# 列出用户主目录下超过 3 天未修改的目录看一遍再说 find /home -maxdepth 2 -type d -name .cache -mtime ${DAYS_OLD}5. 功能测试与效果验证脚本写出来后不能直接当生产工具用要先做一轮可观察的测试确认删除范围、释放空间和存在的问题。5.1 测试一查看清理前后空间变化正式执行前先记录基线# 记录当前磁盘空间 df -h /tmp/disk_before.txt # 执行清理脚本 bash cleanup_demo.sh # 查看清理后的磁盘空间 df -h如果释放空间不明显不要急着把所有文件都删掉先看占用最大的目录是不是没被规则覆盖。5.2 测试二验证清理不会影响日常使用清理后做一次“最常用操作巡检”打开浏览器看网页缓存是否正常重建。进入一个 Python 项目启动服务确认__pycache__能自动生成代码能正常运行。打开终端执行 dnf 或者 apt update确认包管理器缓存不会导致源信息丢失。如果 Linux 的 journald 日志被清理到 500M用 journalctl -u sshd --since today 检查近期系统服务日志是否仍然可用。如果这些操作都正常说明清理策略没有碰到底层运行所需文件。5.3 测试三模拟误删与文件恢复正规清理前应该先做一次“假删除”测试。Linux 下可以把 rm 换成 mv把文件移动到回收目录等观察几天没问题再真正删除。例如#!/bin/bash # dry_run_cleanup.sh # 假删除把过期临时文件移动到 /tmp/cleanup_trash 而不是真的删除 TRASH/tmp/cleanup_trash mkdir -p $TRASH find /tmp -maxdepth 2 -type f -mtime 3 -exec mv {} $TRASH/ \; 2/dev/null find /tmp -maxdepth 2 -type d -empty -delete 2/dev/null echo 文件已移动到 $TRASH确认无误后可执行 rm -rf $TRASH这样即使误删除也能在 /tmp/cleanup_trash 里找回来。观察 3 到 7 天后确认系统运行稳定再执行真正删除。5.4 测试四验证应用恢复机制做缓存清理测试时应该重点看“应用删除缓存后能否自动重建”。比如删除~/.cache/chromium后重新打开浏览器看是否能正常生成新的缓存目录。如果某个应用在缓存被删后出现设置丢失那这个路径应该从清理名单里去掉。6. 自动化定时清理与任务编排清理不能只靠“某天想起来才执行”。磁盘占用是持续增长的过程尤其日志和临时文件会定期涨回来。建议把清理脚本挂到系统定时任务里。6.1 Windows 任务计划程序在 Windows 下用任务计划程序定时执行 PowerShell 脚本# 创建每天凌晨 2 点执行清理的任务 $action New-ScheduledTaskAction -Execute powershell.exe -Argument -ExecutionPolicy Bypass -File C:\Scripts\cleanup_demo.ps1 $trigger New-ScheduledTaskTrigger -Daily -At 02:00 Register-ScheduledTask -TaskName DailyDiskCleanup -Action $action -Trigger $trigger -Force注意任务运行失败时可以在“任务计划程序”的“历史记录”里查看错误常见问题是脚本路径不对、权限不足、正在执行时被用户锁屏策略限制。6.2 Linux crontabLinux 下将脚本加入 crontab# 编辑当前用户的定时任务一般用户加 sudo 后执行 crontab -e # 每天凌晨 3 点执行清理脚本 0 3 * * * /bin/bash /usr/local/scripts/cleanup_demo.sh /var/log/disk_cleanup_cron.log 21有两点需要补充crontab 环境变量和 PATH 与登录 shell 不同脚本内尽量写绝对路径如果脚本需要 root 权限建议放在 root 的 crontab 里# root 用户的 crontab sudo crontab -e6.3 多级日志管理不管是用任务计划程序还是 crontab都需要把清理过程的日志保存下来。日志文件本身也会增长所以要在日志中加轮转策略。Linux 下推荐使用 logrotate# /etc/logrotate.d/disk-cleanup /var/log/disk_cleanup.log { weekly rotate 4 compress missingok notifempty }Windows 下没有 logrotate脚本中可以用 Start-Transcript 并定期清理 Transcript 文件或者直接在脚本里判断日志文件大小超过 10MB 就重命名一份。7. 清理后的性能与空间评估清理完成后不要只看“剩余空间变大了多少”这一个指标要从两个维度观察观察项命令预期结果磁盘总剩余空间df -h /剩余空间应明显增加具体数字取决于清理范围日志目录大小变化du -sh /var/log日志目录应回到配置上限以内临时目录大小变化du -sh /tmp旧的未使用文件被清掉用户缓存目录变化du -sh ~/.cache体积应下降系统启动时间uptime 对比前后清理后第一次冷启动可能稍慢因为缓存重建第二次应恢复正常开机后应用启动速度浏览器/IDE 启动计时缓存清空后首轮启动可能变慢随后恢复这里的结论比较通用缓存存在的意义就是加速。清理缓存会释放空间但也会让下一次访问变慢。所以清理策略不要一味追求“清到 0”而是要把空间控制在一个合理范围内。例如 npm 的 _cacache 目录如果只有几百 MB就没必要每次清理journald 限制在 500M 就够用。如果服务器上运行着 Docker不要忽略 Docker 自身的垃圾占用# 查看 Docker 系统级占用 docker system df # 清理悬空镜像、停止的容器、无用网络和构建缓存 docker system prune -f注意docker system prune 不会删除正在使用中的镜像和容器这是相对安全的清理但在执行 docker system prune -a 之前要注意它会删除所有未被容器使用的镜像重新拉取会消耗时间。8. 常见问题与排查方法问题现象可能原因排查方式解决方案清理后剩余空间几乎没有变化大文件不在清理规则内或者删除时被文件占用跳过用 du 按目录找出占用最大的路径细化规则补充清理路径删除时报 Permission denied当前用户没有该目录的写权限查看路径属主ls -ld /path以管理员或 root 身份执行删除时报 File in use应用程序正在使用文件Windows 常见于浏览器或 IDE关闭对应进程后再执行在脚本中加入尝试跳过而非中断的逻辑journalctl --vacuum-size 后空间没变小journald 服务可能没有立即释放磁盘空间journalctl --disk-usage 查看实际占用重启 systemd-journald 服务清理后某些软件出现配置丢失缓存目录包含应用状态数据比如数据库临时文件检查软件文档确认目录用途将该目录从清理名单中移除Windows 系统更新缓存删不掉Windows Update 服务仍在运行先 Stop-Service wuauserv停服务后删除删除后再启动服务apt autoremove 误删软件没有提前查看将被删除的包列表执行 sudo apt --dry-run autoremove只删除确定无用的依赖Docker 清理后镜像重新拉取时间过长删除了本地镜像缓存docker images 查看本地镜像按需保留常用镜像不要滥用 prune -a清理脚本定时任务不执行crontab 环境变量或脚本权限不对手动执行脚本看是否报错查看 /var/log/cron脚本写绝对路径检查执行权限处理这些问题的核心思路是先看日志再手动复现不要一上来就扩大删除范围。日志会告诉你哪些文件删成功了哪些文件被跳过跳过的原因通常是权限或占用。9. 最佳实践与使用建议9.1 清理策略分级将清理规则分成三个级别级别清理对象执行频率低风险用户临时目录、回收站、过期浏览器缓存每周一次中风险系统日志、包管理器缓存、构建产物每两周一次高风险整个缓存目录、下载目录、未记录路径手动执行先备份在脚本里低风险和中风险可以自动跑高风险路径不要放进自动任务。9.2 路径规则要明确不要写“删除某个目录下所有文件”这种极简规则要把每条规则拆成三个要素目录范围、文件时间条件、文件类型条件。例如# 删除 /var/log/ 下超过 7 天、以 .log 结尾、非空文件 find /var/log -type f -name *.log -mtime 7 -size 1k -delete9.3 日志和审计清理动作算是一种“写操作”可能影响线上数据完整性。即使只在自己电脑上执行也应该保留日志。日志里至少要记录这些信息执行时间、每个清理路径的操作数量、跳过原因、异常信息。Linux 里可以用 tee 同时输出到终端和文件Windows 里可以用 Start-Transcript。9.4 隐私与数据合规清理的临时文件里可能包含聊天图片、网页保存的截图、浏览器表单自动填充记录、可恢复的已删除文件。处理这类文件而不是纯粹的脚本清理企业电脑上的磁盘清理要符合公司数据安全规定不要用个人习惯去删别人机器上的缓存文件。如果清理的对象是同事或用户提供的异常磁盘不要在他人的机器上执行未知来源的清理脚本。如果脚本清理的目录里可能存在受版权保护的下载文件、企业内部文档或涉及隐私的截图先确认归属再决定是否删除。9.5 防止删除后恢复成本过高删除之前先问三个问题这个文件是否能在需要时重新生成能生成则缓存类文件可删。这个文件是否能从远端重新下载能下载则临时副本可删。这个文件是否唯一存在唯一且没有备份则不删。如果三个问题的答案都不明确就不要进入自动删除名单。10. 总结与下一步磁盘清理不是一个需要频繁折腾的事情但它需要一套能被重复执行的方案。今天这篇文章给了一种不依赖第三方全家桶的思路先用 du/df 看空间分布再按“系统临时文件 - 应用缓存与日志 - 开发项目产物”的顺序逐层清理最后把常用命令收敛成脚本和定时任务。这套方法最直接的价值是让你知道每一次删除操作到底删了什么以及在哪里找回误删的内容。如果你想快速上手我给出的行动顺序是先用 du/df 和 ncdu 找到磁盘占用最大的目录。在 Windows 上执行一遍 4.4 节的 PowerShell 脚本模拟测试在 Linux 上先跑 dry_run_cleanup.sh。确认脚本没有误删个人文档和应用配置后加入定时任务。两周后检查一次 journald 日志、Docker 空间和项目构建产物根据新的占用分布调整清理规则。真正容易踩的坑是三类第一把不分青红皂白的 rm -rf 当万能钥匙第二清理后不验证应用是否能正常恢复第三把清理脚本挂在定时任务里就跑路完全不管日志。后续还可以扩展的方向很多。如果你管理多台 Linux 服务器可以结合 Ansible 把清理脚本分发到所有机器如果你主要用 Windows可以再接一个小型看板脚本定期把剩余空间数值写到文本文件里观察趋势如果你负责 CI 流水线可以在每次构建结束后自动清理构建器缓存。磁盘空间的治理不是一次性的而是从“到处找空间”变成“定时清理 设置上限 观察趋势”的可控过程这套思路会比任何一款商业清理工具都更透明也更适合写进自己的运维体系。