最直接有效的方式是用 find 按时间自动清理：/tmp 用 -mtime +1，/var/tmp 用 -mtime +7；必须通过宝塔计划任务执行带日志的 Shell 脚本，禁用 rm -rf /tmp/*，并避开正在使用的文件。
清理 /tmp 和 /var/tmp 临时文件最直接有效的方式
宝塔服务器磁盘爆满，/tmp 目录常年堆积大量临时文件（如 PHP 会话、上传缓存、编译中间件），是高频空间杀手。手动清一次治标不治本，必须靠定时自动清理。
- 优先用
find按时间清理，避免误删正在使用的文件：find /tmp -type f -mtime +1 -delete（删除 1 天前的普通文件） -
/var/tmp同理，但部分服务（如 systemd-tmpfiles）会往里写长期缓存，建议设为+7天更稳妥：find /var/tmp -type f -mtime +7 -delete - 别直接
rm -rf /tmp/*—— 会干掉正在运行进程的 socket、pid 文件，导致 Nginx/PHP 报 502 或服务假死 - 如果清理后出现 502，大概率是删了
/tmp/php-cgi-*.sock，重启 PHP 服务即可恢复
用宝塔计划任务执行 Shell 清理脚本的实操要点
宝塔的「计划任务」是唯一推荐的自动化入口，图形化配置省去 Cron 编辑风险，但几个关键点常被忽略。
- 任务类型必须选
Shell脚本，不是“备份网站”或“定时访问 URL” - 执行周期建议设为每天凌晨 2–3 点低峰期，例如
0 2 * * *（每天 2:00） - 脚本内容不要只写一条命令，加个日志记录更安心：
find /tmp -type f -mtime +1 -delete && echo "$(date): /tmp cleaned" >> /www/server/panel/logs/clean_tmp.log - 注意权限：计划任务以
root身份运行，无需加sudo；但若脚本中调用了自定义路径（如/www/server/php/80/var/session），得确认该路径存在且可读
为什么不能只依赖 PHP 自带的 session GC？
很多人以为改了 session.gc_maxlifetime 就万事大吉，实际在宝塔环境下效果极差 —— 因为 PHP-FPM 的子进程模型让 GC 触发概率极低，/tmp/sess_* 文件动辄堆积数万。
- 宝塔默认 PHP 配置中
session.save_path = "/tmp"，所有会话都落进/tmp，和系统临时文件混在一起 - 即使把
session.gc_probability改成1、session.gc_divisor改成100，GC 仍只在每次请求时随机触发，无法覆盖静默期长的站点 - 更可靠的做法是：保留 GC 设置（防突发堆积），同时用定时任务单独清理
/tmp/sess_*：find /tmp -name "sess_*" -mmin +30 -delete（30 分钟未访问即删）
清理前务必检查是否影响正在运行的服务
/tmp 不是垃圾桶，而是 Linux 系统级临时工作区，有些服务会持续写入并依赖其中的文件结构。
- 清理前先看哪些进程正占用
/tmp：lsof +D /tmp 2>/dev/null | head -20，重点关注nginx、php-fpm、mysqld是否有打开的文件 - 宝塔自身日志压缩包藏在
/www/server/panel/logs，里面*.tar.gz文件虽在logs目录，但本质也是临时产物，建议一并纳入清理范围 - 某些 PHP 扩展（如 XCache、OPcache）可能把缓存写进
/tmp，若发现清理后页面报错，检查phpinfo()中相关扩展的缓存路径是否被误删
真正稳定的清理策略，从来不是“删得越狠越好”，而是明确每条命令影响的边界——比如 -mtime +1 比 -delete 多一个判断条件，就少一次半夜救火。
