服务器跑久了，磁盘告急是迟早的事。登录上去 df -h 一看，根分区红了，/tmp 塞满了，/var/log 膨胀到几十个 G。挨个目录翻一遍，发现一大半是测试留下的垃圾——压测生成的临时文件、调试用的 dump、跑 benchmark 写出来的数据、随手 wget 下来的安装包、还有各种"先放这儿回头再删"结果再也没回头的东西。

　　这些文件有个共同特点：它们不是系统运行必需的，但也没有明显的标记告诉你"我可以删"。清理的时候最怕两件事，一是删错东西把业务搞挂，二是删了半天发现真正占空间的元凶没动。所以清理测试文件这件事，重点不在 rm 命令本身，而在删之前的排查、确认和防护流程。下面按实际操作顺序讲清楚。

　　第一步：先搞清楚空间到底被谁占了

　　不要上来就 rm -rf。先做全盘扫描，建立一个"占用地图"。

　　最基础的两条命令：

df -h
du -sh /* 2>/dev/null | sort -rh | head -20

　　df -h 看的是文件系统层面的使用率，告诉你哪个挂载点满了。但有个坑：df 显示满了，du 却算出来没那么多，这种情况通常是已删除但被进程占用的文件。文件被 rm 了，但某个进程还持有文件句柄，空间不会释放。这种要用 lsof 找：

lsof +L1

　　或者：

lsof | grep deleted | awk '{print $7, $2, $1, $9}' | sort -rn | head -20

　　第七列是文件大小，第二列是 PID。找到之后重启对应进程，空间才会真正释放。这个坑不先排掉，后面所有的清理都是白费力气。

　　确认没有 deleted 占用后，逐层往下钻：

du -sh /var/* 2>/dev/null | sort -rh | head -20
du -sh /tmp/* 2>/dev/null | sort -rh | head -20
du -sh /home/* 2>/dev/null | sort -rh | head -20

　　一路钻到具体的子目录。常见的大头集中在 /tmp、/var/tmp、/var/log、/var/cache、用户 home 目录下的各种临时工程目录、以及应用自己的数据目录里。

　　如果想快速定位整个系统里最大的那些文件，用 find：

find / -xdev -type f -size +500M -exec ls -lh {} \; 2>/dev/null | awk '{print $5, $9}' | sort -rh | head -30

　　-xdev 的作用是不跨文件系统，避免跑到挂载的网络盘或者其它分区上去，既慢又没意义。

　　第二步：区分"测试文件"和"业务文件"

　　扫描完之后你会看到一堆目录和文件，但哪些能删、哪些不能删，这是清理工作里最需要判断力的部分。测试文件通常有几个特征：

　　命名上有痕迹。 test_、tmp_、debug_、benchmark_、stress_、load_ 这类前缀，或者带时间戳后缀的 xxx_20240115_143022.dat。压测工具生成的文件往往命名很有规律，一眼就能看出来。

　　时间集中在某个区间。 比如某次压测集中在三天前，那批文件的 mtime 就全在那几天。用 find 按时间筛：

find /data -type f -mtime +7 -mtime -30 -ls | head -50

　　这条命令找的是 7 天前到 30 天前之间修改过的文件，正好对应"那次测试完之后就再也没碰过"的典型场景。

　　文件类型是中间产物。 .log、.tmp、.dump、.core、.trace、.prof、.pcap、.sql(测试导入的)、.tar.gz(测试用的安装包)。但要注意，.log 不等于测试文件，业务日志也是 .log。

　　目录结构像临时工作区。 /tmp/loadtest_20240115/、/data/benchmark_run3/ 这种，整个目录都是测试产物。

　　判断的核心原则是：拿不准的，先不删，移到隔离区。 下面会讲隔离区的做法。

　　第三步：建立删除前的防护机制

　　这是整个流程里最重要的一步，也是很多人跳过的一步。直接 rm 的风险在于，命令敲下去就没有后悔药。所以要先做两层防护。

　　第一层：先看再删，用 ls 验证。 任何 find 出来的结果，先不加 -delete 或 -exec rm，而是先用 -ls 或 -exec ls -lh {} \; 把完整列表打出来，人工扫一遍。确认没有误伤再执行删除。

　　第二层：软删除到隔离区。 不要直接删，先移到一个临时目录：

mkdir -p /tmp/trash_$(date +%Y%m%d)
find /data/test_* -type f -mtime +7 -exec mv {} /tmp/trash_$(date +%Y%m%d)/ \;

　　在隔离区放几天，确认业务没受影响，再彻底删除。这个中间缓冲期能救命。如果 mv 跨文件系统慢，或者空间已经紧张到没有余量，那就没法用隔离区，只能靠删除前的人工确认。

　　第三层：关键目录做备份。 如果清理的是 /etc、应用配置目录、或者数据库数据目录附近的东西，先 tar 打包一份放到别的盘上，哪怕只是临时的。删错了还能恢复。

　　第四步：分类清理的具体操作

　　临时目录

　　/tmp 和 /var/tmp 是最常见的重灾区。系统通常有 systemd-tmpfiles 或 tmpwatch 自动清理，但规则不一定覆盖你的场景。

　　手动清理超过 7 天没动过的文件：

find /tmp -type f -atime +7 -delete
find /var/tmp -type f -atime +7 -delete

　　注意用 -atime(访问时间)而不是 -mtime(修改时间)。临时文件的价值在于"最近有没有被访问"，一个文件可能三个月前创建但每天都在读，用 -mtime 会误删。

　　清理空目录：

find /tmp -type d -empty -delete

　　日志文件

　　业务日志不能直接删，但可以按大小或时间清理旧的归档日志。常见做法：

find /var/log -name "*.log.*" -mtime +30 -delete
find /var/log -name "*.gz" -mtime +30 -delete

　　.log.1、.log.2.gz 这种是 logrotate 转出来的历史归档，超过一定期限删掉是安全的。但正在写入的 .log 文件不要直接删，要用 truncate 清空：

truncate -s 0 /var/log/某应用.log

　　直接 rm 正在写的日志，进程还持有句柄，空间不会释放，就变成了前面说的 deleted 占用问题。

　　测试数据目录

　　按名称模式匹配：

find /data -maxdepth 1 -type d -name "*test*" -o -name "*benchmark*" -o -name "*tmp*"

　　先列出结果确认，再删除。用 -maxdepth 1 限制只搜一层，避免深入到业务子目录里误伤。

　　包管理器缓存

　　这个不算测试文件但经常占很大空间，顺手清掉：

# Debian/Ubuntu
apt-get clean

# RHEL/CentOS
yum clean all
dnf clean all

　　应用产生的临时文件

　　很多应用会在自己的目录下生成临时文件，比如 Java 的 hsperfdata、MySQL 的 ib_logfile 旧备份、Docker 的悬空镜像和容器。Docker 的清理是独立话题：

docker system df
docker image prune -a
docker container prune
docker volume prune

　　docker system prune -a 会清掉所有未使用的镜像、容器、网络，杀伤力大，执行前确认没有正在运行但用到的镜像。

　　第五步：把清理变成定期动作

　　手动清理一次解决不了根本问题，测试文件会源源不断地产生。真正有效的方式是配置定期清理任务。

　　用 cron 加一个每周执行的清理脚本：

#!/bin/bash
# /usr/local/bin/cleanup_test_files.sh
LOG="/var/log/cleanup_test_files.log"
echo "===== $(date) =====" >> "$LOG"

# 清理 /tmp 下 7 天未访问的文件
find /tmp -type f -atime +7 -delete >> "$LOG" 2>&1

# 清理 /data/test_* 下 30 天未修改的文件
find /data -maxdepth 1 -type d -name "test_*" -mtime +30 -exec rm -rf {} \; >> "$LOG" 2>&1

# 清理旧日志归档
find /var/log -name "*.gz" -mtime +30 -delete >> "$LOG" 2>&1

echo "done" >> "$LOG"

　　挂到 crontab：

0 3 * * 0 /usr/local/bin/cleanup_test_files.sh

　　每周日凌晨 3 点跑一次。脚本里所有删除动作都记日志，出问题可以回溯。

　　更规范的做法是用 systemd timer 代替 cron，好处是能看执行状态、有日志集成、依赖管理更清晰。但 cron 胜在简单通用，多数场景够用。

　　需要留意的几个注意事项：

　　软链接和硬链接。 find 默认不跟随符号链接，但 rm -rf 一个目录时如果里面有指向外部的软链接，删的是链接本身不是目标，这个没问题。但如果是硬链接，删一个名字不会释放空间，要所有硬链接都删掉才行。排查时用 find / -samefile 文件名 找同一个 inode 的所有链接。

　　挂载点。 清理 /data 下的东西时，如果 /data 下面还挂载了别的分区，du 和 find 会跑进去。加 -xdev 避免跨文件系统。

　　权限。 用 root 跑清理脚本要格外小心，一个路径拼错就可能删到系统关键文件。脚本里所有路径写绝对路径，不要用变量拼接后不检查就直接删。

　　正在使用的文件。 除了日志，数据库文件、socket 文件、锁文件都可能被进程持有。删除前用 lsof 文件路径 确认没有进程在用。

　　清理和业务的时间冲突。 定期清理任务不要安排在业务高峰期，尤其是 find 遍历大目录会消耗 IO。凌晨低峰期执行最稳妥。

　　总结：服务器测试文件清理，流程比命令重要。正确的顺序是：先用 df 和 du 建立占用地图，排查 deleted 文件占用，然后按命名、时间、类型三个维度识别测试文件，删除前通过列表确认和隔离区做防护，分类执行清理(临时目录用 -atime，日志用 truncate 不用 rm，测试数据先列后删)，最后用 cron 或 systemd timer 固化成定期任务。

　　核心原则就一条：任何删除动作之前，先能完整地看到将被删除的东西。 看不到就不删。这个习惯能避免绝大多数清理事故。