df -h 显示挂载点容量增大且使用率未异常飙升，即为扩容成功的唯一可靠标记；它验证文件系统已识别新增空间，而lsblk、fdisk等仅反映底层设备或分区状态，不可替代。
df -h 显示新容量就是最直接的扩容成功标记
扩容操作完成后，df -h 输出中对应挂载点的「容量」列数值变大，且「已用%」未因扩容而异常飙升，就说明文件系统已识别并使用了新增空间。这不是“可能成功”，而是**唯一可靠、用户态可验证的成功标记**。
常见误判点：
- 只看
lsblk—— 它只显示块设备大小（底层磁盘或分区），不反映文件系统是否已扩展； - 只看
fdisk -l或parted -l—— 这些只确认分区表是否更新，和文件系统无关； - 执行了
xfs_growfs或resize2fs但没报错，就认为成功——实际可能因挂载点错误、路径写错（如用了/dev/sdb而不是/dev/sdb1）导致命令静默失效。
确认挂载点与设备名严格匹配
扩容命令作用对象必须和 df -h 显示的「文件系统」列完全一致。例如：
df -h 输出：
/dev/sdb1 xfs 90G 33M 90G 1% /data
→ 扩容命令必须是 xfs_growfs /data（推荐）或 xfs_growfs /dev/sdb1；
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
若误写成 xfs_growfs /dev/sdb（无分区情况除外），命令会执行但无效，df -h 容量不变。
ext4 同理：resize2fs 的目标必须是 df -h 中显示的那个设备路径，不能是父设备或逻辑卷别名（如 /dev/mapper/centos-root 正确，/dev/centos/root 可能失败）。
文件系统类型决定“成功”的行为边界
XFS 和 ext4 对扩容的响应机制不同，直接影响你看到的标记：
- XFS：必须显式运行
xfs_growfs，且该命令**不修改元数据大小，只在线扩展**；成功后df -h立即更新，无中间状态； - ext4：
resize2fs会重写超级块和组描述符，完成后内核自动刷新缓存；但若文件系统被挂载为只读（ro），或处于e2fsck检查中，resize2fs会拒绝执行并报错The filesystem is mounted; resize2fs refuses to operate on a mounted filesystem（除非加-f强制，但不推荐）； - 注意：ext4 在线扩容要求内核支持（≥2.6.10），且不能对根文件系统做在线 resize（某些发行版例外，但风险高）。
真正容易被忽略的细节
很多用户卡在「明明 df -h 没变，但所有命令都跑过了」——问题往往出在：
- 挂载点被重复 mount：执行过
mount /data两次，第二次覆盖了第一次，导致xfs_growfs /data实际作用于旧挂载实例； - 使用了 LVM 但漏掉
lvextend：只跑了xfs_growfs，但逻辑卷本身没扩大，文件系统再怎么“grow”也无空间可用； - 云环境未触发分区表重读：扩容后未运行
partprobe或udevadm trigger，内核仍按旧分区大小提供设备节点，后续所有操作都基于错误尺寸。
所以，df -h 是终点，但不是孤立信号——它必须和你执行的每一步目标设备、挂载状态、LVM 层级严格对齐。差一个字符，就差整个空间。
