<p>df -h仅显示挂载点剩余空间，需用du -sh组合筛选定位具体大文件或目录，如du -sh /var/log/* | sort -hr查日志中最大项，并注意df与du差异源于统计层面不同（文件系统块vs目录树）。</p>
直接看 df -h 只能知道“哪个挂载点剩多少”，但没法告诉你“/var/log 里哪个日志文件占了 20G”——要查具体分布，必须组合 du 和筛选手段。
用 du -sh 快速定位大目录
这是最常用也最容易被忽略的第一步。du 统计的是目录实际占用的磁盘空间（含子目录），不是文件大小总和（比如硬链接、稀疏文件会影响结果）。
-
du -sh /var/*：列出/var下一级所有目录的总大小，单位自动换算 -
du -sh /home/* | sort -hr | head -10：按大小倒序排，取前 10 个最大项 - 别漏掉隐藏目录：
du -sh /root/.* /root/* 2>/dev/null | sort -hr（2>/dev/null屏蔽权限错误） - 注意：
du默认统计的是“已分配块”，所以一个 1MB 的文件如果只写了 1KB 但分配了整块，也会算作 4KB（取决于文件系统块大小）
du -ah + sort -h 找出单个大文件
当怀疑是某个具体文件撑爆磁盘时，这招最直接。但要注意性能开销——遍历整个 / 很慢，建议限定路径。
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
-
du -ah /var/log | sort -h | tail -20：查/var/log下最大的 20 个文件（含子目录里的） -
du -ah /tmp | grep 'G\|M$' | sort -h：只显示 GB/MB 级别的条目，避免被 KB 条目淹没 - 常见陷阱：
du不会进入其他挂载点（比如/proc、/sys），但如果你加了-x参数（du -ahx /），它就真的只查根文件系统，不会跨挂载点——这点常被误用
为什么 df 和 du 结果不一致？
这不是 bug，而是底层机制差异导致的常见困惑，直接影响你判断“空间到底去哪了”。
-
df读取文件系统超级块，反映的是整个分区的已用/可用块数 -
du遍历目录树，统计每个文件实际占用的数据块 - 典型不一致场景：
- 有进程正在写一个大文件，然后被
rm删除了——文件没真正释放，df显示已用空间没变，但du已经看不见它了 - 文件系统保留了 5% 的空间给 root（ext4 默认），
df的 “Available” 会扣掉这部分，du不体现 - 存在硬链接或 reflink（如 btrfs），同一数据块被多个路径引用，
du默认只算一次，df看的是块总数
- 有进程正在写一个大文件，然后被
配合 lsof + deleted 检查“消失却占空间”的文件
当 df 显示空间已满但 du 加起来远小于该值，大概率是有被删除但仍被进程打开的文件。
-
lsof +L1：列出所有 link count = 0 的打开文件（即已被rm但未关闭的） -
lsof -nP | grep deleted | head -10：快速筛出前十条，看 PID 和文件路径 - 确认后可 kill 对应进程，或让其主动 close 文件句柄——别直接
echo > /proc/PID/fd/N清空，可能破坏应用逻辑 - 注意：
lsof需要 root 权限才能看到所有进程，普通用户只能看到自己的
真正难的不是命令本身，而是理解 df 和 du 分别在哪个层面工作；很多“空间莫名消失”的问题，其实只是你没意识到内核、文件系统、进程三者对“空间”的定义根本不同。
