宝塔面板添加定时清理任务本质是添加crontab规则，应优先通过Web界面操作以避免与手动编辑冲突；脚本需用绝对路径、显式指定解释器、处理环境变量和权限问题，并安全筛选删除文件。
宝塔面板里添加定时清理任务，本质就是加一条 crontab 规则
宝塔的「计划任务」功能底层调用的就是系统 crontab，所有操作最终都会写入 /var/spool/cron/root（或对应用户）。直接在宝塔界面添加最稳妥，避免手动编辑 crontab -e 后被宝塔同步覆盖或冲突。
常见错误现象：手动用 crontab -e 加了清理命令，但过段时间发现失效——大概率是宝塔后台「计划任务」列表里有同名/同周期任务，或者宝塔重启后重载了自己维护的 crontab 文件。
- 优先通过宝塔 Web 界面添加，路径：「计划任务」→「添加计划任务」→ 类型选「Shell 脚本」
- 脚本内容不要写绝对路径依赖的环境变量（如
$HOME），建议显式指定/bin/bash或/usr/bin/python3 - 如果脚本需读取用户级配置（如
~/.bashrc），要在脚本开头加source /root/.bashrc（注意：宝塔默认以 root 用户运行）
写一个安全的清理脚本：避免误删、保留最近 N 天日志和备份
直接 rm -rf /www/backup/* 风险极高。真实场景中，应按时间筛选，且排除正在使用的文件（如当前 Nginx 日志、未完成的数据库导出）。
示例：清理 /www/backup/site 下 7 天前的 .zip 备份，但跳过带 keep 标签的文件：
#!/bin/bash find /www/backup/site -name "*.zip" -type f -mtime +7 ! -name "*keep*" -delete
关键点：
-
-mtime +7表示「修改时间超过 7 天」，不是「创建时间」；若需按创建时间，Linux 默认不支持，得用stat+find -exec组合（性能差，慎用） -
! -name "*keep*"是排除逻辑，比用grep -v更可靠（避免管道中断导致部分文件没删） - 务必先用
find ... -print测试匹配结果，确认无误再换-delete
宝塔计划任务执行失败的三个高频原因
脚本在终端能跑通，但宝塔定时执行时报错或静默失败，通常卡在这三处：
- 路径问题：
cd /www/wwwroot/example.com在脚本里可能失败，因为宝塔执行时工作目录是/root，建议所有路径写绝对路径，或开头加cd /www/wwwroot/example.com || exit 1 - 权限问题：比如清理
/www/wwwroot/xxx/runtime/cache，但该目录属主是www用户，而宝塔计划任务默认用root运行，rm没问题，但某些 PHP 清理脚本需www权限才能删 session 文件——此时要改计划任务的「执行用户」为www - 环境变量缺失：脚本里用了
php artisan，但宝塔 cron 环境里$PATH不含/www/server/php/82/bin，解决方法是在脚本开头加export PATH="/www/server/php/82/bin:$PATH"
清理 Nginx/Apache 日志时，别碰正在写的 access.log
直接 rm /www/wwwlogs/example.com.log 可能导致日志丢失，因为 Nginx 进程还持有着该文件句柄。正确做法是用 logrotate 或发信号重开日志文件。
宝塔自带日志切割，但如果你要用 crontab 手动切，推荐方式：
mv /www/wwwlogs/example.com.log /www/wwwlogs/example.com.log.$(date +\%Y\%m\%d) kill -USR1 $(cat /www/server/nginx/logs/nginx.pid)
说明：
-
kill -USR1通知 Nginx 重新打开日志文件，它会新建access.log并继续写入 - 不要用
echo "" > access.log清空，这会破坏文件 inode，Nginx 仍往旧位置写，磁盘空间不会释放 - 宝塔「网站」→「日志切割」设置里勾选「自动切割」，其实就等价于定期执行类似上面的逻辑
真正容易被忽略的是：多个站点共用一个 Nginx 实例时，kill -USR1 会重开所有站点日志，所以确保所有日志路径都已配置好，否则可能产生空文件或权限错误。
