服务器跑久了，磁盘空间总在不知不觉中被吃掉。登录一看，`/tmp` 目录下堆了几万个 session 文件，`/var/tmp` 里躺着几个月前的编译残留，再加上各种应用的临时缓存——这些“看不见的垃圾”累积起来，轻则拖慢系统响应，重则把磁盘写满导致服务崩溃。

临时文件不会自己消失，除非你给它设定好“自动销毁”的规则。这篇文章从清理策略到具体配置，手把手教你用系统原生工具和面板工具实现临时文件的自动清理。

先搞清楚：临时文件都在哪，谁该被清理

服务器上产生临时文件的主要位置有三处，清理策略各不相同。

`/tmp` 是系统级临时目录，存放进程运行时产生的短期文件——PHP session、上传临时块、编译中间产物、socket 文件等。这个目录的特点是“用完即弃”，但很多进程不会主动清理自己的临时文件，需要系统层面的机制来兜底。

`/var/tmp` 的定位和 `/tmp` 类似，但区别在于它要求文件在重启后依然保留。系统规范明确建议 `/var/tmp` 中的文件保留时间更长，通常设为 7 天到 30 天不等。

应用级临时目录容易被忽略，比如 PHP 的 session 存储路径、Docker 的容器日志、Nginx 的 `proxy_temp` 等。这些目录的清理策略需要根据应用特性单独设定，不能一刀切。

清理前有一个关键检查：确认 `/tmp` 是否挂载为 tmpfs。如果执行 `df -Th /tmp` 显示类型为 `tmpfs`，说明它占的是内存而不是磁盘，清理它不会释放磁盘空间，反而可能消耗内存。这种情况下应该把清理重点转向 `/var/tmp` 和实际写入磁盘的应用目录。

方案一：systemd-tmpfiles——现代Linux的推荐方案

对于使用 systemd 的现代 Linux 发行版（Debian 10+、Ubuntu 18.04+、CentOS 8+、Rocky Linux 等），`systemd-tmpfiles` 是系统原生的临时文件管理工具，开箱即用，不需要额外安装任何软件。

它的工作原理是：通过配置文件定义“目录+保留时间”的规则，由 `systemd-tmpfiles-clean.timer` 定时触发清理。默认配置通常已经存在，你只需要确认定时器是否正常运行，然后按需调整保留时间即可。

检查定时器状态：

systemctl status systemd-tmpfiles-clean.timer

systemctl list-timers --all | grep tmpfiles

如果定时器处于 `active (waiting)` 状态，说明自动清理已经在运行。

自定义清理规则：

系统默认规则位于 `/usr/lib/tmpfiles.d/tmp.conf`，不建议直接修改这个文件。正确做法是在 `/etc/tmpfiles.d/` 下创建自己的配置文件，它会覆盖同名默认规则。

创建 `/etc/tmpfiles.d/local.conf`：

清理 /tmp 中超过 7 天未访问的文件

d /tmp 1777 root root 7d

清理 /var/tmp 中超过 30 天未访问的文件

d /var/tmp 1777 root root 30d

排除 systemd 私有临时目录，避免影响 PrivateTmp=yes 的服务

x /tmp/systemd-private-%b-

X /tmp/systemd-private-%b-/tmp

规则中 `d` 表示目录类型，`1777` 是权限（含 sticky bit），`7d` 和 `30d` 分别表示超过 7 天和 30 天未访问即删除。最后的 `x` 和 `X` 用于排除 systemd 私有目录，这是必须添加的保护规则。

配置修改后，可以先手动执行一次清理验证效果：

sudo systemd-tmpfiles --clean

`--clean` 参数会按照配置的 age 参数清理所有超期文件。

方案二：tmpwatch——传统RHEL系的选择

如果你使用的系统没有 systemd，或者习惯用独立工具来控制清理逻辑，`tmpwatch` 是 Red Hat 系发行版的经典方案。

它的核心逻辑是按文件的访问时间（atime） 判断是否过期，默认只删除超过指定时间未被访问的普通文件和空目录。

安装与基本用法：

CentOS / RHEL

sudo yum install tmpwatch -y

手动清理 /tmp 中超过 7 天未访问的文件

sudo tmpwatch 7d /tmp

`7d` 表示保留 7 天，单位可以是小时（默认）、天（d）、分钟（m）或秒（s）。

配置为每日自动执行：

在 `/etc/cron.daily/` 下创建脚本 `/etc/cron.daily/tmpwatch-clean`：

!/bin/sh

/usr/sbin/tmpwatch 7d /tmp

/usr/sbin/tmpwatch 30d /var/tmp

然后赋予执行权限：`sudo chmod +x /etc/cron.daily/tmpwatch-clean`。这样系统每天会自动执行一次清理。

tmpwatch 有一个实用参数 `--test`，可以在真正删除前先查看哪些文件会被清理，适合在第一次配置时验证规则是否合理。

方案三：宝塔面板——图形化定时清理

对于使用宝塔面板的用户，最稳妥的方式是通过「计划任务」功能执行 Shell 脚本，而不是直接使用 `rm -rf` 命令。

操作路径： 登录宝塔 → 左侧菜单「计划任务」→ 添加任务 → 类型选「Shell脚本」。

清理 `/tmp` 的脚本内容：

!/bin/sh

find /tmp -type f -mtime +1 -delete

echo "$(date): /tmp cleaned" >> /www/server/panel/logs/clean_tmp.log

这条命令删除 `/tmp` 中超过 1 天未修改的普通文件。`-mtime +1` 确保至少存在 1 天，防止刚生成的临时文件被误删。

清理 `/var/tmp` 的脚本内容：

!/bin/sh

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

echo "$(date): /var/tmp cleaned" >> /www/server/panel/logs/clean_var_tmp.log

`/var/tmp` 的保留时间建议设为 7 天以上，因为部分服务会在这里存放需要跨重启保留的缓存。

执行周期： 建议设为每天凌晨 2:00-3:00，避开业务高峰和备份时段。Cron 表达式为 `0 2   `。

宝塔环境下特别需要注意的

宝塔默认将 PHP session 存储在 `/tmp` 目录下，`sess_` 文件动辄堆积数万个。仅靠 PHP 自身的 session GC 机制效果有限，因为 PHP-FPM 的子进程模型让 GC 触发概率极低。

可以在计划任务中增加一条针对 session 文件的清理：

find /tmp -name "sess_" -mmin +30 -delete

这条命令删除 30 分钟未访问的 session 文件，比依赖 PHP GC 更可靠。

同时，宝塔的回收站（`/www/Recycle_bin`）是隐藏的空间杀手。用户在面板中删除的文件实际上以硬链接形式保留在此目录，不会显示在磁盘图表中。建议每月手动进入「文件」→「回收站」执行一次清空。

清理策略的核心原则

无论使用哪种方案，有几条原则是共通的。

不要直接 `rm -rf /tmp/`。 这会删除正在运行进程的 socket 文件和 pid 文件，导致 Nginx、PHP 等服务报 502 错误或假死。应该使用基于时间阈值的 `find` 命令，让“最近使用过的文件”得到保护。

先测试再删除。 在正式执行清理命令前，把 `-delete` 替换为 `-print`，查看哪些文件会被删除。确认无误后再换成实际删除操作。

重要操作前做好快照。 如果你使用的是华纳云云服务器，可以在执行大规模清理操作前通过控制台为磁盘创建快照。快照是磁盘级别的完整镜像，如果清理脚本误删了关键文件，可以快速回滚到清理前的状态，不需要逐文件恢复。

生产环境每月一次全面清理，开发测试环境每周一次。 这是经过大量运维实践验证的节奏。

华纳云：为自动化维护提供稳定的底层环境

临时文件的自动清理依赖 Cron 或 systemd timer 定时执行，这些任务能否准时触发，取决于服务器本身的稳定性。如果服务器频繁重启或资源紧张导致 Cron 守护进程被延迟执行，清理任务就可能“错过窗口”。

华纳云香港及美国节点接入 CN2 GIA 精品线路，三网直连优化，从国内通过 SSH 管理服务器、调整清理配置的操作体验流畅稳定。全系标配企业级 NVMe SSD，磁盘 I/O 性能远超普通 SATA SSD，无论是 `find` 命令遍历大量临时文件还是数据库导出备份，响应速度都更有保障。独享带宽确保远程管理不会因为“邻居抢带宽”而超时中断。