先用 df -h 和 df -ih 定位空间与 inode 耗尽的挂载点，再在该分区执行 du -sh /* | sort -hr 找顶层目录，接着用 find + du 深挖大文件和旧日志，最后验证占用、必要性及管理机制后谨慎清理。
df -h 看清哪个分区真满了
别一上来就 du，先确认问题在哪儿：df -h 输出里 Use% 超过 90% 的那个挂载点才是目标。比如 /dev/sda1 挂在 /，那就盯死根目录；如果是 /dev/sdb1 挂在 /var，那后续所有操作都限定在 /var 下——跨分区查 / 下的 du 会漏掉真实大户。
顺手加个 df -ih /，避免 inode 耗尽导致“空间没满却写不了文件”的假象。很多残留临时文件（尤其是日志轮转产生的 .1、.2.gz）数量多但单个体积小，容易把 inode 撑爆。
du -sh /* 2>/dev/null | sort -hr 找出顶层罪魁
在确认的满分区下执行这句，能快速暴露吃空间的顶级目录。常见高危目标：
-
/tmp和/var/tmp：服务崩溃后遗留的未清理 socket、lock 文件或大体积临时数据 -
/var/log：旧日志没轮转、journald日志没限制、应用自己写的未压缩日志 -
/var/cache：apt/dnf缓存、pip下载包、docker构建中间层（/var/lib/docker） -
/root或/home/*：用户下载的镜像、备份包、未清理的 tar.gz
注意：du -sh /* 会因权限跳过部分目录（如 /proc、/sys），所以末尾加 2>/dev/null 屏蔽报错，不影响结果排序。
find + du 定位残留临时文件和缓存的具体路径
对上一步锁定的可疑目录，用组合命令深挖：
查 /tmp 下大于 100MB 的孤立文件：find /tmp -type f -size +100M -exec ls -lh {} \;
查 /var/log 下 7 天前的普通日志（避开正在写的 syslog）：find /var/log -type f -name "*.log" -mtime +7 -ls
查 /var/cache 各子目录真实大小：du -sh /var/cache/* 2>/dev/null | sort -hr
关键细节：
-
-mtime +7是修改时间超 7 天，不是创建时间；有些服务写日志用追加模式，mtime可能比实际存在时间新 -
find ... -ls比-print多显示权限、大小、时间，一眼识别是否是残留而非活跃文件 - 看到
/var/cache/apt/archives/占几十 MB 正常，但若达 GB 级，说明apt clean长期没跑
清理时别直接 rm -rf，先验证再动手
列出路径只是第一步，删之前必须确认三点：
- 该路径是否被进程占用？运行
lsof +D /path/to/dir，若有输出，说明文件正被使用，硬删会导致空间不释放（Linux 的“已删除但未关闭”状态） - 该目录是否为服务运行时必需？例如
/tmp/systemd-private-*是 systemd 服务私有临时区，重启服务后自动重建，可清；但/tmp/.X11-unix是 X11 socket 目录，删了图形界面可能崩 - 是否已有自动化机制在管？比如
/var/tmp下的文件若由systemd-tmpfiles管理，应优先改配置（/usr/lib/tmpfiles.d/*.conf），而不是手动删
真正要删时，用 find ... -delete 比 rm -rf 更可控——它只删匹配条件的文件，不会误伤同级其他内容；但务必先去掉 -delete，换成 -ls 或 -print 预览一遍。
最易被忽略的点：某些残留文件（如 Docker 的 dangling image、journal 日志）不显式落在 /tmp 或 /var/cache 下，而是藏在 /var/lib/docker/overlay2 或 /var/log/journal/ 这类路径里，得靠 du -sh 逐层钻进去，不能只信目录名。
