必须先用 df -h 确认真实爆满分区，再分层 du 下钻定位日志目录，清空前需判断是否被进程占用，优先 truncate 清空而非 rm 删除，mysql binlog 和 journal 日志须按规范清理。
直接删日志前，必须先确认它是不是真凶——90% 的“磁盘满”误判，都源于没搞清到底哪个分区、哪个目录在吃空间。
先用 df -h 锁定真实爆满分区
面板卡死或提示“磁盘使用率 95%”，别急着进 /www/wwwlogs 狂删。先 SSH 登录，跑这句：
df -h
盯住 Use% 列超过 90% 的那行，记下它对应的 Mounted on 路径，比如是 / 还是 /www。后面所有操作都从这个路径开始——如果 /dev/vda1 满了但挂载点是空的，说明那是未挂载盘，跟当前问题无关。
常见误区：
- 看到“宝塔”就默认去
/www扫，结果发现真正占满的是/var或系统根分区 - 用
du -sh /*全盘扫，慢、干扰多、还可能因权限被中断
用 du 分层下钻，快速定位日志目录
假设 df -h 显示 /www 是主战场，那就聚焦它：
du -sh /www/* 2>/dev/null | sort -hr | head -10
重点关注这些典型日志聚集地：
-
/www/wwwlogs/：网站access.log、error.log，单个文件动辄几 GB -
/www/server/data/：MySQLmysql-bin.*（binlog），不关自动清理会涨到几十 GB -
/www/server/panel/logs/：面板自身操作日志，request/下可能堆积大量未轮转文件 -
/www/Recycle_bin/：宝塔回收站，删了文件但没清空该目录 = 空间照占
如果发现某个 .log 文件每分钟增长几 MB，大概率是程序异常（如死循环写日志），得先停服务查代码，不是单纯清日志能解决的。
安全清日志：别直接 rm -f，优先用 truncate 或 cat /dev/null >
直接删正在被 Nginx/PHP 写入的日志文件，会导致新日志写不进去、服务报错。更稳妥的做法是清空内容，保留文件句柄：
cat /dev/null > /www/wwwlogs/example.com.log
或者用 truncate（更明确）：
truncate -s 0 /www/wwwlogs/example.com.log
对 MySQL binlog 这类敏感日志，必须先停 MySQL 服务再删：/www/server/panel/plugin/mysql/index.py stop，否则重启可能失败。
systemd journal 日志不能 rm -rf /var/log/journal，会破坏索引。正确姿势是：
journalctl --vacuum-size=100M
或限制保留时长：
journalctl --vacuum-time=7d
用图形化磁盘分析器辅助验证（非必需但省心）
如果命令行排查后仍不确定，可临时上传绿色版磁盘分析工具（如 WinDirStat 类 Linux 替代品）到服务器，或本地挂载后扫描。它用色块矩阵直观标出最大文件，悬停即见完整路径，特别适合识别那些不在宝塔常规路径下的自定义日志（例如应用写到 /data/logs/ 或 /home/wwwroot/app/runtime/log）。但注意：这类工具扫描过程本身会占内存和 I/O，生产环境慎用；且扫描结果只是参考，最终删什么，还得结合 ls -lh 和业务逻辑判断。
真正卡住人的，往往不是找不到大文件，而是删完发现 df -h 没变化——这时候要检查 SQLite 数据库（如 /www/server/panel/data/default.db）删表后是否执行了 VACUUM，还有被进程锁住的文件是否真的释放了 inode。
