磁盘清理实战：用系统自带命令搭建Windows/Linux一键清理脚本

这次我们不聊算法，也不聊模型部署，直接聊一个每个开发者都会遇到的事：磁盘满了。一开始可能是 C 盘飘红，后来可能是 /home 分区报警，再往后是 Docker 镜像把磁盘吃到连编译都不想启动。很多人第一反应是找“清理软件”，结果发现满网都是下载按钮比清理按钮还明显的全家桶工具。我的建议是，先把第三方清理工具放一边，用系统自带的命令和脚本，自己搭一套“一键清理”流程。这套方案能覆盖 Windows 和 Linux，能看清楚每个被删文件的来源，也能在误删之后快速定位问题。

这篇文章会围绕一条主线展开：什么样的文件可以安全清理，怎么把平时零散的清理命令收敛成一个可直接执行的脚本，以及清理之后如何验证效果、如何避免再次被日志和缓存塞满。如果你已经对重复的“磁盘空间不足”提示感到头疼，可以把这套方法当成一个长期可用的运维习惯，而不是每次用完就忘的一次性操作。

1. 核心能力速览

很多“磁盘清理工具”的卖点是界面好看、按钮大，但底层做的事情无非就是删除临时文件、清空回收站、清理缓存。自己搭一套脚本方案，优势不在于功能数量，而在于可解释和可控。下面是这套方案的速览：

这套方案的目标不是“把所有文件都删到最小”，而是把磁盘空间分为“可安全释放”“有风险”“不可动”三类，然后只处理第一类。这样做的好处是，即使清理逻辑出现误判，问题范围也是可控的。

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%\Temp
  • C:\Windows\Temp
  • C:\Windows\SoftwareDistribution\Download
  • C:\Users<用户名>\AppData\Local\CrashDumps
  • C:\Users<用户名>\AppData\Local\Microsoft\Windows\Explorer

Windows 下面不要直接删除 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 清理前一定要做的事

清理前要做三件基础工作：

1. 关闭正在运行的软件：浏览器、IDE、容器、数据库这类会持续写缓存的服务先停掉，避免删除正在使用的文件。
2. 备份重要数据：至少要备份数据库目录和项目源码目录。
3. 确认当前磁盘剩余空间：清理后能马上对比结果。

# 查看当前磁盘空间 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.log"

Windows 更新缓存经常占用很大空间，但对普通用户来说，已经安装完成的更新缓存是可以清理的：

# 清理 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-time=7d journalctl --vacuum-size=500M

也可以直接修改 journald 配置，让日志上限长期生效：

# 编辑 /etc/systemd/journald.conf # 设置 SystemMaxUse=500M sudo sed -i 's/#SystemMaxUse=/SystemMaxUse=500M/' /etc/systemd/journald.conf sudo systemctl restart systemd-journald

包管理器缓存是另一个大块。Ubuntu/Debian 用 apt，CentOS/Rocky 用 dnf：

# Ubuntu / Debian sudo apt clean sudo apt autoremove --purge -y # CentOS / Rocky / Fedora sudo dnf clean all sudo dnf autoremove -y

apt 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/_cacache

pip 的缓存也能清理：

# 清理 pip 下载缓存 pip cache purge

Maven 的本地仓库缓存通常不需要全删，但可以删除.lastUpdated后缀的下载失败残留文件：

# 删除 Maven 下载失败的残留标记文件，不会影响正确下载的依赖 find ~/.m2/repository -name "*.lastUpdated" -delete

Go 的模块缓存可以查看大小后按需清理：

# 查看 Go 模块缓存大小 go clean -modcache

go 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_OLD=3 THRESHOLD_SIZE="500M" 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 crontab

Linux 下将脚本加入 crontab：

# 编辑当前用户的定时任务，一般用户加 sudo 后执行 crontab -e # 每天凌晨 3 点执行清理脚本 0 3 * * * /bin/bash /usr/local/scripts/cleanup_demo.sh >> /var/log/disk_cleanup_cron.log 2>&1

有两点需要补充：crontab 环境变量和 PATH 与登录 shell 不同，脚本内尽量写绝对路径；如果脚本需要 root 权限，建议放在 root 的 crontab 里：

# root 用户的 crontab sudo crontab -e

6.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. 清理后的性能与空间评估

清理完成后，不要只看“剩余空间变大了多少”这一个指标，要从两个维度观察：

这里的结论比较通用：缓存存在的意义就是加速。清理缓存会释放空间，但也会让下一次访问变慢。所以清理策略不要一味追求“清到 0”，而是要把空间控制在一个合理范围内。例如 npm 的 _cacache 目录如果只有几百 MB，就没必要每次清理；journald 限制在 500M 就够用。

如果服务器上运行着 Docker，不要忽略 Docker 自身的垃圾占用：

# 查看 Docker 系统级占用 docker system df # 清理悬空镜像、停止的容器、无用网络和构建缓存 docker system prune -f

注意：docker system prune 不会删除正在使用中的镜像和容器，这是相对安全的清理，但在执行 docker system prune -a 之前要注意，它会删除所有未被容器使用的镜像，重新拉取会消耗时间。

8. 常见问题与排查方法

处理这些问题的核心思路是：先看日志，再手动复现，不要一上来就扩大删除范围。日志会告诉你哪些文件删成功了，哪些文件被跳过，跳过的原因通常是权限或占用。

9. 最佳实践与使用建议

9.1 清理策略分级

将清理规则分成三个级别：

在脚本里，低风险和中风险可以自动跑，高风险路径不要放进自动任务。

9.2 路径规则要明确

不要写“删除某个目录下所有文件”这种极简规则，要把每条规则拆成三个要素：目录范围、文件时间条件、文件类型条件。例如：

# 删除 /var/log/ 下超过 7 天、以 .log 结尾、非空文件 find /var/log -type f -name "*.log" -mtime +7 -size +1k -delete

9.3 日志和审计

清理动作算是一种“写操作”，可能影响线上数据完整性。即使只在自己电脑上执行，也应该保留日志。日志里至少要记录这些信息：执行时间、每个清理路径的操作数量、跳过原因、异常信息。Linux 里可以用 tee 同时输出到终端和文件；Windows 里可以用 Start-Transcript。

9.4 隐私与数据合规

清理的临时文件里可能包含聊天图片、网页保存的截图、浏览器表单自动填充记录、可恢复的已删除文件。处理这类文件而不是纯粹的脚本清理：

• 企业电脑上的磁盘清理要符合公司数据安全规定，不要用个人习惯去删别人机器上的缓存文件。
• 如果清理的对象是同事或用户提供的异常磁盘，不要在他人的机器上执行未知来源的清理脚本。
• 如果脚本清理的目录里可能存在受版权保护的下载文件、企业内部文档或涉及隐私的截图，先确认归属，再决定是否删除。

9.5 防止删除后恢复成本过高

删除之前，先问三个问题：

1. 这个文件是否能在需要时重新生成？能生成，则缓存类文件可删。
2. 这个文件是否能从远端重新下载？能下载，则临时副本可删。
3. 这个文件是否唯一存在？唯一且没有备份，则不删。

如果三个问题的答案都不明确，就不要进入自动删除名单。

10. 总结与下一步

磁盘清理不是一个需要频繁折腾的事情，但它需要一套能被重复执行的方案。今天这篇文章给了一种不依赖第三方全家桶的思路：先用 du/df 看空间分布，再按“系统临时文件 -> 应用缓存与日志 -> 开发项目产物”的顺序逐层清理，最后把常用命令收敛成脚本和定时任务。这套方法最直接的价值是让你知道每一次删除操作到底删了什么，以及在哪里找回误删的内容。

如果你想快速上手，我给出的行动顺序是：

1. 先用 du/df 和 ncdu 找到磁盘占用最大的目录。
2. 在 Windows 上执行一遍 4.4 节的 PowerShell 脚本模拟测试，在 Linux 上先跑 dry_run_cleanup.sh。
3. 确认脚本没有误删个人文档和应用配置后，加入定时任务。
4. 两周后检查一次 journald 日志、Docker 空间和项目构建产物，根据新的占用分布调整清理规则。

真正容易踩的坑是三类：第一，把不分青红皂白的 rm -rf 当万能钥匙；第二，清理后不验证应用是否能正常恢复；第三，把清理脚本挂在定时任务里就跑路，完全不管日志。

后续还可以扩展的方向很多。如果你管理多台 Linux 服务器，可以结合 Ansible 把清理脚本分发到所有机器；如果你主要用 Windows，可以再接一个小型看板脚本，定期把剩余空间数值写到文本文件里，观察趋势；如果你负责 CI 流水线，可以在每次构建结束后自动清理构建器缓存。磁盘空间的治理不是一次性的，而是从“到处找空间”变成“定时清理 + 设置上限 + 观察趋势”的可控过程，这套思路会比任何一款商业清理工具都更透明，也更适合写进自己的运维体系。