必须手动配置logrotate，因宝塔日志切割功能仅处理两类文件、不压缩、份数固定、周期不可调且忽略关键日志路径；需创建独立规则文件，严格匹配路径与权限，并启用delaycompress、验证语法及手动触发测试。
直接开干：几十 GB 的日志不是配置没开，而是默认全关 + 没压缩 + 不清理。必须手动配 logrotate，宝塔自带的「日志切割」功能只切一部分、不压缩、不可调周期，撑不住高流量站。
为什么宝塔自带日志切割不管用
它只处理 /www/wwwlogs/域名.log 和 /www/wwwlogs/域名.error.log 这两类文件，且：
- 不压缩（只重命名，比如
example.com.log-20260420），磁盘压力一点没减 - 保留份数写死为 30，不能按站点单独设（API 站点留 7 天，官网留 90 天？做不到）
- 执行时间固定在每天 00:30，服务器那会儿离线就跳过，不补执行
- 完全不管
/www/server/panel/logs/（面板自身日志）、/www/server/nginx/logs/（Nginx 自身 error.log）、/var/log/journal/（systemd 日志）
必须手动配置 logrotate 并验证路径与权限
核心是建一个不会被宝塔升级覆盖的规则文件，比如 /etc/logrotate.d/bt-custom，内容要严格匹配实际路径和用户权限：
-
/www/wwwlogs/*.log和/www/server/panel/logs/*.log必须同时写进同一段配置，否则得维护多个文件 -
create 644 www www这行不能少，且www必须和 Nginx 工作用户一致（宝塔默认就是www），否则轮转后新日志创建失败，open() "/www/wwwlogs/xxx.log" failed (13: Permission denied) -
delaycompress必须启用：本次轮转只重命名，下次才压缩，避免 Nginx 向已压缩文件继续写入导致丢日志 - 测试语法是否合法：
sudo logrotate -d /etc/logrotate.d/bt-custom（-d是 debug 模式，不真正执行） - 手动触发一次验证：
sudo logrotate -f /etc/logrotate.d/bt-custom，成功后应看到access.log.1或panel.log.1.gz
清理历史垃圾日志前先确认文件是否还在被写入
常见陷阱：df -h 显示 /www 分区 98%，但 du -sh /www/* 加起来才 40 GB——说明有被 rm 掉但进程还在写的大文件，空间没释放。
- 查被删除但未释放的日志：
lsof +L1 | grep wwwlogs或lsof +L1 | grep "deleted" - 若发现 Nginx 正在往已删的
access.log写，需发信号让它切到新文件：kill -USR1 $(cat /www/server/nginx/logs/nginx.pid) - 别直接
rm -rf /www/wwwlogs/*，先用find /www/wwwlogs -name "*.log" -mtime +90 -print看匹配哪些，确认无误再换-delete - systemd-journald 日志常占几 GB，默认无配额，必须手动设：
sudo mkdir -p /etc/systemd/journald.conf.d && echo -e "[Journal]\nSystemMaxUse=500M" | sudo tee /etc/systemd/journald.conf.d/limit.conf，然后sudo systemctl restart systemd-journald
定时任务别混用宝塔计划任务和 crontab 手动编辑
宝塔「计划任务」底层就是管理 /var/spool/cron/root，手动改 crontab -e 极易冲突或被覆盖。
- 所有定时操作统一走宝塔 Web 界面：「计划任务」→「添加计划任务」→ 类型选「Shell 脚本」
- 脚本里所有路径写绝对路径，比如
/bin/bash、/usr/bin/find，别依赖$PATH - 如果清理脚本要删
www用户目录下的缓存，记得把「执行用户」从默认root改成www，否则可能权限拒绝 - 清理命令加
! -name "*keep*"这类排除逻辑，比grep -v更可靠，防止管道中断漏删
最易忽略的一点：logrotate 规则里的 rotate N 表示最多保留 N 个归档文件，不是 N 天——如果某天没日志产生，就不会生成归档，实际保留天数可能远超预期。需要精确控制天数，得配合 find 脚本按修改时间清理。
