90%的“不知名文件”实为宝塔或其依赖服务（mysql、systemd、日志轮转）产生的膨胀数据，需用du -sh /* | sort -hr | head -10定位根目录大目录，再针对性清理default.db等sqlite表。
直接说结论：90% 的“不知名文件”根本不是病毒或黑客留下的，而是宝塔自己或它依赖的服务（MySQL、systemd、日志轮转）在长期运行中失控膨胀的数据库、二进制日志、journal 日志或 SQLite 表，必须用命令定位，不能只靠面板点点删。
du -sh /* | sort -hr | head -10 定位根目录级大块头
面板卡死、网站全挂时，先别急着进文件管理器——它可能根本打不开。用 SSH 连上，第一件事就是看哪个顶层目录吃掉了空间：du -sh /* 2>/dev/null | sort -hr | head -10。注意 2>/dev/null 是为了屏蔽权限拒绝报错，否则会刷屏干扰判断。常见高危目标：/www（网站+备份+回收站）、/var（日志和缓存）、/root（意外下载的大包）、/opt（Docker 镜像）。如果输出里 /www 占了 40G，下一步就只查它，别去翻 /boot 或 /proc ——它们不可能撑到爆盘。
宝塔自己的 default.db 膨胀到几十 GB 怎么办
很多人清完日志、回收站、MySQL binlog，空间还是不释放，最后发现 /www/server/panel/data/default.db 独占 28G。这不是损坏文件，是宝塔把所有访问记录、安全扫描结果、计划任务日志全塞进这张 SQLite 表里，且从不自动清理。直接删会丢面板配置，但清空表又不缩容——SQLite 删除后页不返还。正确做法分两步：
- 先用
sqlite3 /www/server/panel/data/default.db "DELETE FROM boce_list WHERE id 删掉旧数据（保留最新 10 万条） - 再执行
sqlite3 /www/server/panel/data/default.db "VACUUM"强制回收磁盘空间
journalctl --disk-usage 显示 /var/log/journal 占 5G+ 必须限制
CentOS/RHEL 系统默认开启 systemd-journald，日志全堆在 /var/log/journal/，没人管就滚到 10G 以上，且面板完全不显示这个路径。运行 journalctl --disk-usage 一眼就能确认。临时清理用 journalctl --vacuum-size=200M，但治本要改配置：
- 编辑
/etc/systemd/journald.conf - 取消注释并设为
SystemMaxUse=200M和MaxRetentionSec=1week - 执行
systemctl restart systemd-journald
mysql-bin.000xxx 和 /www/backup 里藏着“静默炸弹”
MySQL 二进制日志和宝塔自动备份目录是两个最常被忽略的静默炸弹：
-
mysql-bin.000xxx文件在/www/server/data/下，单个就 1G，累积几十个直接吞光剩余空间。停 MySQL 后删比在面板里点“清理”更彻底，因为面板有时只清日志内容，不删文件本身 -
/www/backup里可能有几个月前的全站压缩包，名字像site_20250812.zip，面板备份列表里早没了，但它还在硬盘上躺着。用ls -lt /www/backup/ | head -5按时间倒序列出最近几个，再人工判断哪些能删
df -h 对比，确保删的是真凶，不是刚写入一半的数据库文件。真正麻烦的从来不是“找不到大文件”，而是删完发现空间没回来——那说明你删的是软链接、内存映射文件，或者 SQLite / journal 没触发物理释放。这时候必须回到 du 和 journalctl 这类底层命令，而不是反复刷新面板首页看 Use% 数字。
