结论是：用find精准定位大文件，du+sort发现目录级“隐形巨无霸”，ncdu交互式清理——但须避坑：勿全盘find、勿误删活跃日志、勿跳过占用确认。
直接说结论：用 find 查，用 du+sort 排，用 ncdu 交互删——但别一上来就加 -exec rm，误删根目录下 /var/log/journal 或容器日志这种“看不见的大户”是高频事故。
用 find 按大小精准定位文件
这是最可控的起点，find 的 -size 参数单位容易错：+100M 表示“严格大于 100MB”，但 100M 不等于 100MB（Linux 中 M = 1024×1024 字节），而 +100M 和 +100MB 在多数 GNU find 版本中等价，但 Alpine 或 BusyBox 环境可能不支持 B 后缀，只认 k/M/G。
-
find /var -type f -size +500M：查 /var 下所有大于 500MB 的普通文件（排除目录、设备文件等） - 加
-xdev防跨分区：比如你只扫/home，但不想误入挂载的 NFS 或 Docker volume：find /home -xdev -type f -size +1G - 加
-mtime +7过滤“老而大”的文件，避开正在写入的日志：find /tmp -type f -size +100M -mtime +7 - 别用
find / -size +1G全盘扫：会卡住、触发 OOM Killer，尤其在低内存 VPS 上
用 du + sort 发现“隐形巨无霸”
find 只看单个文件，但有些“大”是目录堆出来的，比如 /var/lib/docker/overlay2 或 /home/user/.cache；du 才能暴露真实磁盘占用。常见错误是直接 du -sh *，结果被 /proc、/sys 权限拒绝打断，或被符号链接绕晕。
- 安全起见加
--max-depth=1和2>/dev/null：du -sh --max-depth=1 /var/* 2>/dev/null | sort -hr | head -10 - 要精确到文件级且跳过目录？组合
find：find /var -type f -exec du -h {} + | sort -hr | head -20 -
sort -hr中的h是关键——它识别1.2G、456M这类人类可读格式；没h就按字典序排，99M会排在100M前面
删之前必须确认文件是否还在被进程占用
直接 rm -f 一个正在被 tail -f、rsyslogd 或 Java 应用写入的日志文件，磁盘空间不会立刻释放——Linux 的 inode 还被进程持有着，得靠 lsof 或 /proc/*/fd 查证。
- 查谁在写大文件：
lsof +L1列出所有已删除但仍被打开的文件（即“已删未释放”） - 查具体大文件被谁占着：
lsof /var/log/syslog.1（替换为你找到的路径） - 真要清空而非删除？用
truncate -s 0 <file></file>，比> <file></file>更可靠（后者在某些 shell 下可能因权限失败） - 删完记得
sync一下，尤其在物理机或 RAID 卡上，避免缓存延迟导致df显示不准
交互式清理推荐 ncdu，但注意它的默认行为
ncdu 看起来友好，但它默认递归扫描整个目录树，第一次运行 ncdu / 可能卡死 10 分钟以上。而且它的“删除”是 rm -rf，不区分文件/目录——选中一个软链接，按 d 会删掉目标，不是链接本身。
- 先限制范围：
ncdu /home或ncdu /var/log，别一上来扫/ - 扫描中按
t可切换排序依据（大小/名称/修改时间），按n过滤文件名（比如输log只看日志） - 删除前它会显示完整路径并二次确认，但如果你用的是 SSH 复制粘贴操作，确认提示可能被吞掉——务必看清高亮行再按
y - 容器环境慎用：宿主机跑
ncdu /var/lib/docker可能触发 overlay2 层级锁，导致容器卡住
真正麻烦的从来不是命令记不住，而是 /var/log/journal 这种 systemd 日志、Docker 的 json.log、或用户家目录里藏在 .cache 深处的 2GB Chrome 缓存——它们不常出现在 find -size +1G 结果里，却占满磁盘。每次清理前，先 df -h 看哪块挂载点告急，再决定从哪一层开始挖。
