df 命令需结合 -h、-T、-i 和过滤使用才能准确识别磁盘风险：Use% 受保留空间和文件系统差异影响，tmpfs 的 100% 不代表磁盘满，inode 耗尽比空间不足更致命，且 total 行无实际意义。
df 是查看 Linux 磁盘使用率最直接的命令，但它默认输出的是块单位（1K-blocks），不加参数几乎没法快速判断哪块盘快满了。关键不是“能不能看”，而是“怎么看清、看准、不漏关键风险”。
df -h 显示人类可读的使用率，但别只信 Use% 这一列
执行 df -h 后，Use% 看似直观，但容易误判：
-
Use%计算基于“用户可用空间”，不包含 root 保留空间（通常是 5%，ext4 默认）。一块标称 95% 的盘，实际可能还有几百 MB 可写——但普通用户进程已无法写入 - 某些挂载点（如
/dev/shm、tmpfs）是内存虚拟文件系统，Use%涨到 100% 不代表磁盘真满，只是内存吃紧 - 如果看到
/或/var分区Use%超过 85%，必须立刻配合du追查，而不是等它到 95%
df -hT 查文件系统类型，避免误判 xfs/ext4/btrfs 行为差异
不同文件系统对空间预留、延迟分配、inode 管理策略不同，df -hT 能帮你提前预判风险点：
-
xfs默认不预留空间，Use%接近 100% 时可能突然拒绝写入（尤其小文件密集场景） -
ext4有 5% 保留块，df显示 95% 时 root 还能写，但普通服务（如 nginx、mysql）通常以普通用户运行，实际已不可写 -
btrfs的Use%包含元数据开销，且支持配额，单看df容易低估真实压力 - 若发现
overlay或zfs类型，说明在容器或 ZFS 环境中，df显示的是上层挂载点，底层池空间需另查
df -i 查 inode 耗尽风险，比磁盘满更隐蔽也更致命
磁盘空间还有 20GB，但 df -i 显示 Use% 是 99%？那服务大概率已经挂了——尤其是日志轮转、邮件队列、临时上传目录这类小文件密集场景：
-
df -i输出中的IUsed和IUse%才是关键，IUse%> 90% 就该清理或扩容 - 常见罪魁：/var/log/journal（systemd-journald）、/var/spool/postfix、/tmp 下堆积的临时文件、Docker 容器未清理的 overlay 差分层
-
find /path -xdev -type f | cut -d/ -f2 | sort | uniq -c | sort -nr | head -5可快速定位哪个子目录生成最多 inode
df -h --total 加总行，但要注意 tmpfs 和 network fs 的干扰
df -h --total 末尾会多一行 total，看似方便，但这个“总”毫无业务意义：
- 它把
tmpfs（内存）、nfs（远程）、cgroup2（容器控制组）全加进去了，和物理磁盘容量完全无关 - 真正要盯的是
/、/home、/var、/data这类本地块设备挂载点，建议用df -h | grep '^/dev/'过滤 - CentOS 7.9 等老系统中，
df -h --total在某些内核版本下会因 procfs 边界计算错误多加一行，数值不准，不如手动加
真正卡住系统的，往往不是“磁盘满”，而是某个分区的 inode 耗尽、某类 tmpfs 占用过高、或者 df 看不到的未挂载 LVM 逻辑卷空间碎片。别只盯着 Use% 数字，得结合挂载点语义、文件系统类型、inode 状态一起看。
