应逐级下钻用 du -sh 定位深层大目录，避免依赖宝塔面板显示；需加 2>/dev/null 屏蔽权限错误，用 --max-depth 和 grep 过滤聚焦可疑路径，并检查软链接、挂载点及被进程占用的已删文件。
用 du -sh 逐级下钻，别跳过中间层
直接在 /www 下跑 du -sh * 只能看到一级子目录大小，但真正吃空间的往往藏在二级甚至三级路径里（比如 /www/wwwroot/example.com/runtime/cache 或 /www/wwwroot/api/app/storage/logs）。不往下挖，就容易误判“日志已清空”，实际是框架缓存占了 12G。
实操建议：
- 先定位大目录：
du -sh /www/* 2>/dev/null | sort -hr | head -10 - 再进疑似目标（如
/www/wwwroot）执行：du -sh /www/wwwroot/* 2>/dev/null | sort -hr | head -10 - 若发现某个站点目录异常大，继续下钻：
du -sh /www/wwwroot/example.com/{public,storage,logs,runtime} 2>/dev/null | sort -hr -
2>/dev/null是必须加的，否则权限不足的目录会刷屏报错，干扰排序结果
du --max-depth 控制扫描深度，避免卡死或漏关键路径
du -sh 默认递归到底，对含大量小文件的目录（如 Laravel 的 storage/logs）可能耗时数分钟，且输出冗长。用 --max-depth=N 能快速聚焦可疑层级，但要注意：N=1 可能漏掉深层嵌套缓存，N=3 又可能混入无关子目录。
推荐组合：
- 查网站根下前三层：
du -sh --max-depth=3 /www/wwwroot/* 2>/dev/null | grep -E "G|M$" | sort -hr - 只看单个站点的第四层以内（常含
vendor、node_modules）：du -sh --max-depth=4 /www/wwwroot/example.com/* 2>/dev/null | sort -hr | head -5 - 注意
grep -E "G|M$"是过滤出真正需要关注的大文件，跳过 KB 级噪音
避开 du 统计偏差：软链接、挂载点、已删除但未释放的文件
du 默认统计文件系统块占用，但遇到三类情况会不准：软链接指向外部路径、mount --bind 目录被重复计算、进程仍持有已 rm 文件的句柄（常见于 Nginx/PHP-FPM 日志）。这些不会在 du 输出中体现，却真实占磁盘。
验证与处理：
- 检查软链接是否跨分区：
ls -la /www/wwwroot/example.com/storage，若指向/data/cache，得去/data分区单独扫 - 确认是否有隐藏挂载：
mount | grep "/www"，若看到/dev/vdb1 on /www/backup type xfs，说明/www/backup实际空间归属另一块盘，du结果不能代表/www主分区压力 - 查被进程锁住的日志：
lsof +L1，输出中带deleted字样的文件需重启对应服务（如systemctl restart nginx）才能真正释放空间
别信面板首页的“网站使用量”，它根本不统计子目录
宝塔面板在【网站】列表页显示的“磁盘使用”只是该站点根目录（如 /www/wwwroot/example.com）的 du -sh 值，且**不包含其子目录中的符号链接目标、不刷新缓存、不识别 bind 挂载**。你看到“使用 800MB”，实际 /www/wwwroot/example.com/storage/logs 已涨到 6GB，面板照样显示 800MB。
所以必须手动进终端操作。最简验证方式：
- 进站点根目录：
cd /www/wwwroot/example.com - 运行：
du -sh .[!.]* * | sort -hr | head -5（含隐藏文件，如.env、.git、.dockerignore） - 特别注意
node_modules和vendor—— 它们通常比代码本身大 5~10 倍，且宝塔从不提醒你删
真正难的是判断“该不该删”：框架生成的 storage/framework/views 可安全清空，但 storage/app/public 可能是用户上传文件；runtime/cache 能删，runtime/sessions 删了会导致用户登出。动手前先 ls -lt 看修改时间，再结合程序文档确认目录用途。
