陆拾贰號1. 问题背景与现象确认
先说结论：腾讯云上买了系统盘扩容，云控制台里确实看到“硬盘大小”变成了目标值，但登录服务器一执行 df -h，根分区还是原来那个容量。这个现象我从第一次遇到到现在，已经被问过不下二十次，几乎每个没接触过云硬盘扩容机制的新手都会踩一遍。
不夸张地讲，这个问题的本质是：云厂商做的扩容动作，是把“虚拟磁盘”这块“地皮”给扩大了，但地皮上的“分区表”和“文件系统”还停留在旧尺寸。 打个比方，你买了一块100平的地，之前只圈了60平做院子，现在地产商把地皮扩到了120平，但院子的围墙还杵在60平的位置——围墙不会自己往外移，你必须手动把围墙拆掉重砌。
这里要区分两个层面：
- 云控制台层面的扩容：腾讯云帮你把底层虚拟磁盘（云硬盘）的容量上限调大，这一步由云平台完成，不需要你操作服务器内部。
- 操作系统层面的扩容：需要登录服务器，进入系统内部，对分区表执行扩容操作，再对文件系统执行扩容操作，让操作系统真正“认到”新增的空间。
很多教程会把这两个步骤混在一起讲，导致用户以为“云平台扩容完就万事大吉”，实际上操作系统层面的操作才是真正决定“内部空间能否变大”的关键。我见过最典型的场景是：
用户买了50G系统盘，用着用着发现空间不够，直接在控制台把系统盘调整到80G，然后等了几分钟，满心以为“重启一下就完事了”，结果
df -h一看还是50G，甚至重启后依然是50G。
这一篇就把这个问题的完整链路讲透，包含原因、排查手段、实操步骤，以及我踩过的一些坑。我不只会告诉你“怎么敲命令”，还会解释每条命令到底在做什么，为什么要这样敲，方便你以后换到阿里云、AWS、UCloud等其他平台也能举一反三。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 扩容前必懂的两个关键概念
2.1 分区表、文件系统与“扩张”的层级关系
很多人把“磁盘容量”和“分区容量”混为一谈，这其实是两个完全不同的东西，搞清楚它们，后面所有操作都不会慌。
整个存储结构是分层的：
- 物理磁盘：比如
/dev/vda，是一整块云硬盘，容量由云平台控制，扩容就是把它调大。 - 分区：磁盘上划分出来的区域，比如
/dev/vda1，分区有自己的起始和结束扇区，写入磁盘头部的“分区表”里。 - 文件系统：在分区之上格式化的逻辑层，比如 ext4、xfs，它负责管理文件、目录、权限这些“内容组织”的事。
当你在腾讯云控制台把系统盘从50G扩到80G时，云平台做的事情是：把 /dev/vda 这块物理磁盘从50G变成80G。但 /dev/vda1 这个分区还是“50G的边界”，因为分区表的记录没有更新；而文件系统只知道“我的分区是50G”，它当然也不会主动变成80G。
所以云控制台的扩容，只相当于把“整块蛋糕”加大了，但“切蛋糕的刀痕”和“蛋糕上画的格子”都没变。你吃掉的部分仍然只有50G，多出来的30G只是“看得见、用不着”的蛋糕奶油。
这里有个必须点明的坑：不同云厂商、不同镜像、不同分区的扩容工具不同，你要先搞清楚自己的系统用的是什么分区表格式。
传统的老式分区表叫MBR（Master Boot Record），它最多支持2T容量，而且一个磁盘上分区数量和位置有诸多限制。现代服务器和云主机基本都用GPT（GUID Partition Table），支持超大容量，也更稳定。腾讯云的新建云主机默认都是GPT分区表，但如果你是从早期老镜像迁移过来的，可能还会遇到MBR。
MBR分区扩容和GPT分区扩容的命令并不完全一致，下文实操部分我会把最常见的GPT场景讲清楚，同时给出MBR场景的注意事项。
2.2 为什么云控制台扩容后，内部空间没变？
这一节的答案用一句话概括就是：因为分区表和文件系统的“元数据”没有被更新。 展开讲，有三个原因：
-
云平台不会也不能自动修改你操作系统内部的系统盘分区表，因为部分底层的分区操作、文件系统扩展逻辑涉及内核与分区工具，平台侧无法统一兼容所有镜像。为了稳定性，腾讯云只提供底层磁盘扩容，把“改分区表”这件事留给用户在系统内部处理，这是云厂商的通用策略。
-
操作系统是否支持“在线扩容分区”与文件系统类型有关。ext4 支持在线扩容，xfs 也支持在线扩容，但工具和命令不同；如果你用的是 LVM 逻辑卷管理，链路又多了一层（PV→VG→LV），每一步都需要手动扩展。
-
运行中的内核没有及时刷新磁盘分区信息。有些情况下分区已经被工具改大了，但内核缓存里还是旧的分区表信息，这时候需要
partprobe或重启系统让内核重新读取。
这三个原因叠加，造成了用户看到的“假象”：控制台明明显示80G，系统里却还是50G。
我还遇到过一种非常魔幻的边界情况：控制台已经扩容，系统内部 fdisk -l 看到的硬盘容量也变成80G了，但 df -h 还是50G。这种情况说明磁盘层已经搞定，只是分区没有扩大，或者分区扩大后文件系统没有重新读取——命令没敲完整，只走了一半路。
3. 动手之前，先把准备工作做扎实
3.1 快照备份：扩容操作前最值得花的几分钟
如果你在网上搜“腾讯云 系统盘扩容”，很多教程会直接教你敲命令，但我必须先把“备份”放在第一位。不是客套话，而是我真实吃过亏。
有一次我在一台生产环境上执行分区扩容，因为命令参数少打了一个“+”，导致分区表错乱，系统直接无法启动。幸好提前做了快照，最后一个电话让腾讯云售后帮忙回滚，恢复了数据，不然损失非常大。
腾讯云控制台里的操作路径是：
云服务器 → 实例 → 快照 → 创建快照
创建快照前，建议勾选“包含数据盘”，防止系统盘以外的数据也丢。快照创建速度取决于磁盘大小与当前负载，一般是分钟级，50G左右的系统盘通常3-5分钟就能完成。如果数据变动频繁，尽量在业务低峰期操作，避免快照时数据不一致。
需要提醒一句：快照不等于实时备份，它是一个时间点的数据副本。 如果你在扩容后对文件系统做了写入操作，再回滚快照，那扩容后的数据可能丢掉。所以正确的节奏是“先快照，再操作，操作过程中不要有业务写流量”。
3.2 确认系统版本、文件系统类型与分区表格式
这是整个排查链路里最容易忽略的一步。不同系统、不同文件系统类型会走向完全不同的扩容命令，我见过太多人因为没看清文件系统类型，把 resize2fs 用在 xfs 文件系统上，直接报错。
登录服务器后，第一步先跑这几个命令：
bash复制# 查看当前磁盘容量与挂载情况
df -hT
lsblk
fdisk -l /dev/vda
# 查看文件系统类型
blkid
这里我以最常见的腾讯云 CentOS 7/8、Ubuntu 20.04/22.04 系统盘 /dev/vda 举例。不同厂商内部命名可能不同，比如阿里云可能是 /dev/vda 也可能是 /dev/vdb，AWS 一般是 /dev/xvda，但原理一致。
df -hT 的输出里会有一列“Type”，常见取值有：
ext4：老牌默认文件系统，扩容命令是resize2fs。xfs：RHEL/CentOS 7默认文件系统，扩容命令是xfs_growfs，参数是挂载点。btrfs：少数发行版默认，扩容命令是btrfs filesystem resize。LVM：逻辑卷管理，需要先扩PV再扩VG再扩LV，链路复杂一些。
接着用 lsblk 看磁盘和分区的关系：
bash复制NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
vda 253:0 0 80G 0 disk
└─vda1 253:1 0 50G 0 part /
看到没，磁盘 vda 已经显示80G，但分区 vda1 还是50G，这正是云平台只扩了磁盘、没扩分区的典型表现。
有人会问：为什么有的是 vda1 直接挂载在 /，有的却是 vda1 下还有一层 vg-root（LVM）？这是因为两种镜像架构不同。云厂商提供两种最常见的镜像启动方式：
- 非LVM系统盘，分区直接挂载到根目录，扩容路径相对简单。
- LVM系统盘，分区之下还有逻辑卷，常见于部分Ubuntu或定制镜像，扩容路径长，但链条清晰。
实操前最重要的一件事是确认你属于哪种。用 lsblk 看有没有“TYPE”为 lvm 的行就能判断。
3.3 先判断内核有没有“看到”扩容后的磁盘
有些情况下，云控制台扩容后，操作系统的内核依然没有发现磁盘大小变了。判断方法是执行：
bash复制lsblk
如果磁盘容量还是旧值（比如还是50G，而不是80G），也别慌，说明内核还没重新扫描磁盘。可以尝试：
bash复制# 刷新磁盘信息，无需重启
echo 1 > /sys/class/block/vda/device/rescan
但也有部分云环境不支持这种热插拔式rescan，那就只能重启系统了。重启前务必确认没有未保存的配置和运行中的任务，避免造成业务中断。如果重启后 lsblk 能看到新容量，说明内核已经重新识别，可以继续下面的操作。
在这里我要多分享一个细节：腾讯云控制台上系统盘扩容完成后，实例需要“关机再开机”才能让内核发现新容量吗？ 答案是不一定。大部分云环境支持热扩容，但热扩容后内核不一定自动刷新，需要先进系统执行上面的rescan或重启。所以不要一看到容量没变就去找售后，先自己排查内核有没有“看见”。
4. 核心实操：两种场景的完整扩容命令
4.1 场景一：GPT分区 + ext4文件系统
这是最常规的场景，CentOS 7/8、Ubuntu 18.04/20.04默认镜像基本都是这个组合。流程是三步：扩容分区 → 刷新分区表 → 扩展文件系统。
第一步：使用 growpart 扩容分区。
先检查系统有没有 growpart 命令：
bash复制which growpart || yum install -y cloud-utils-growpart
Ubuntu/debian系统用 apt install -y cloud-utils-growpart。
然后执行：
bash复制growpart /dev/vda 1
这条命令的含义是把 /dev/vda 磁盘上的第1个分区扩展到磁盘最大可用空间。注意 /dev/vda 和 1 之间是空格，不是空格也没事，但规范写法是空格。
执行成功后，会输出类似下面的提示：
code复制CHANGED: partition=1 start=2048 old: end=104857599 new: end=167772158
这说明分区从旧的结束扇区扩展到了新的结束扇区。如果输出 NOCHANGE，说明分区已经是最新大小，不需要扩容，或者磁盘没有可用空间。
第二步：刷新分区表。
执行：
bash复制partprobe /dev/vda
或者：
bash复制partx -u /dev/vda
这一步是让内核重新读取分区表，如果不执行，lsblk 可能还是旧的分区信息。如果 partprobe 报错，说设备忙之类，通常是分区正在被使用，此时可以尝试重启，或者强制使用 partx 更新。
第三步：扩展文件系统。
ext4文件系统使用：
bash复制resize2fs /dev/vda1
这个命令会在线扩展文件系统到分区大小，执行后输出类似：
code复制resize2fs 1.42.9 (28-Dec-2013)
Filesystem at /dev/vda1 is mounted on /; on-line resizing required
old_desc_blocks = 6, new_desc_blocks = 10
The filesystem on /dev/vda1 is now 20971520 blocks long.
执行完 df -h 验证：
bash复制df -h
正常情况下根分区已经显示80G了。
4.2 场景二：GPT分区 + xfs文件系统
CentOS 7默认文件系统是xfs，脚本顺序基本相同，只是最后一步命令换成 xfs_growfs。
前两步一样：
bash复制growpart /dev/vda 1
partprobe /dev/vda
第三步改为：
bash复制xfs_growfs /
注意这里参数是挂载点 /，不是分区设备名 /dev/vda1，这是xfs与ext4之间最容易被忽视的差异。xfs_growfs 需要传入挂载点，然后自动扩展该挂载点对应的文件系统。
执行后会输出类似：
code复制meta-data=/dev/vda1 isize=512 agcount=4, agsize=3276800 blks
= sectsz=512 attr=2, projid=64bit
data = bsize=4096 blocks=13107200, imaxpct=25
= sunit=0 swidth=0 blks
...
data blocks changed from 13107200 to 20971520
data blocks changed 这一行代表扩展成功。
为什么ext4和xfs命令不同？ 因为两种文件系统的设计哲学不同：ext4 在扩展时是以块组为单位调整，resize2fs 足够；xfs 的设计是“只增不减”，growfs 只支持增大，不支持减小，所以命令参数直接传挂载点更直观。这也是为什么 xfs 不支持缩小文件系统的原因，在云盘扩容场景下反而没有负担。
4.3 场景三：LVM逻辑卷扩容
碰到LVM的镜像，最典型的特征是在 lsblk 输出里看到：
bash复制vda 253:0 0 80G 0 disk
└─vda1 253:1 0 50G 0 part
└─vg-root 253:2 0 50G 0 lvm /
这里 vg-root 是一个逻辑卷，挂在根目录上。扩容链路是四步：
bash复制# 1. 扩容分区（还是先扩分区）
growpart /dev/vda 1
# 2. 让内核读取新分区
partprobe /dev/vda
# 3. 扩展物理卷（PV）
pvresize /dev/vda1
# 4. 扩展逻辑卷（LV）
lvextend -l +100%FREE /dev/mapper/vg-root
# 5. 扩展文件系统（根据文件系统类型二选一）
resize2fs /dev/mapper/vg-root # ext4
xfs_growfs / # xfs
这里有个很容易踩的坑：pvresize 之后需要确认PV有没有真的扩到80G，用 pvdisplay 查看。如果PV没有变大，后面的 lvextend 会报“no space”之类的错误。
lvextend -l +100%FREE 的含义是把VG剩余的所有空间都分配给这个LV，注意是 -l（小写L）而不是 -L（大写L），前者是“扩展多少个PE”，后者是“扩展多少容量”，写错参数会导致命令行为完全不一样。
如果执行完 lvextend 后不记得文件系统类型，建议用 blkid /dev/mapper/vg-root 先查一下，避免用错命令。
4.4 场景四：MBR分区扩容的边界情况
MBR分区表在老镜像里偶尔还会出现。MBR分区表的特点是主分区最多只能有4个，而且最大只支持2T容量，扩容时如果磁盘超过2T，MBR无能为力，必须转成GPT。但在系统盘扩容场景中，一般不会涉及超过2T的情况，所以重点在于命令层面。
MBR分区扩容依然可以用 growpart，但要注意分区类型，比如 /dev/vda1 对应的分区表类型如果是MBR，growpart 依然能处理。命令写法一样，但执行前建议用 fdisk -l /dev/vda 看清楚分区表类型。
如果 growpart 出现：
code复制growpart: /dev/vda: partition 1 is not a partition table
这类报错，大概率是你传参有问题，或者磁盘压根不是MBR/GPT。请用 parted -l 确认分区表类型。
5. 常见问题与排查技巧实录
5.1 执行 growpart 报错：unexpected output in sfdisk
这是我接到的最多的一类报错。growpart 底层是读取分区表信息，如果你的系统里 sfdisk 版本太老，或者分区表存在特殊标记，就可能报类似：
code复制unexpected output in sfdisk --dump
解决方案有三个思路：
- 升级工具：
yum update -y util-linux后重试。 - 换命令：不用 growpart，直接用
fdisk /dev/vda手动删掉分区重建。注意，这里的“删掉”指的是删除分区记录但保留数据，不是删除分区里的文件，操作时千万小心。 - 用
parted命令：parted /dev/vda resizepart 1 100%，这条命令也能把分区扩展到100%。
我个人最推荐先升级工具，因为手动删分区重建的风险太高，新手极易误操作。
5.2 执行 resize2fs 报错：Filesystem is already 多少 blocks
这个报错其实是好消息，说明文件系统已经是最新大小，不需要再扩展。常见原因是你在 growpart 前就执行了 resize2fs，或者分区本身没变大，resize2fs 只是刷新了确认信息。
遇到这个报错，往回检查分区是否存在剩余空间，用 lsblk 看分区大小是否大于文件系统大小。如果分区没有变大，说明 growpart 没有真正生效，检查内核刷新。
5.3 执行 xfs_growfs 提示：is not a mounted XFS filesystem
这个报错通常是因为参数传错了。xfs_growfs 后面应该跟挂载点，而不是设备文件名，也不应该是分区设备路径。例如：
bash复制xfs_growfs / # 正确
xfs_growfs /dev/vda1 # 错误
如果确定挂载点没问题，再看一下该分区是不是真的挂载了，如果分区没有挂载，执行 mount -a 或者手动挂载。
5.4 扩容后 df 显示正常，但服务还是报磁盘满
这个问题比较隐蔽。df -h 显示80G，但应用依然报 No space left on device，一般有两种情况：
- indoe耗尽：如果你的系统是小文件特别多的场景，文件系统可能有大量inode被占用，
df -i看看。 - 前后端不一致：部分应用缓存了旧磁盘信息，重启进程后可恢复。
- 挂载点下存在隐藏挂载点：某些目录被单独挂载了其他磁盘，比如
/var或/home有独立分区，这时候扩容根分区并不会影响这些目录。
排查命令是：
bash复制df -hi
mount | grep -E ' / | /var | /home '
尤其要注意第三个情况，我遇到过一台机器根分区扩到80G后，/var 还挂着一个独立的小数据盘，日志全往 /var 写，导致 /var 满而根分区空的假性“磁盘满”。
5.5 扩容过程重启后分区表损坏
这是相对少见但极其危险的情况。分区表损坏会导致系统无法启动，唯一有效的办法就是利用之前的快照回滚。因此我再次强调：操作前一定做快照，做完后不要急着在系统里乱写数据。
如果重启后进入紧急模式（Emergency Mode）或者启动失败，可以尝试从腾讯云控制台挂载“救援模式”或“维护模式”，将系统盘挂载到另一台干净实例上检查分区表。但这种操作本身很考验经验，而且不同云平台入口不同，遇到这种情况我建议优先走售后通道。
5.6 扩容到一半，控制台实例状态显示“调整中”持续很久
云控制台上“调整中”的时长一般取决于磁盘大小和底层迁移情况，短则几分钟，长则半小时。如果超过半小时还未完成，需要检查是否有其他调整任务正在互斥执行（比如同时又在调整带宽、重装系统），这种情况下可以等任务结束再观察。不建议反复点击取消或重试，容易造成流程混乱。
6. 工具选型解析：为什么选择 growpart + resize2fs/xfs_growfs
可能有人问，既然 fdisk 也能改分区，为什么要用 growpart？我从实操经验角度讲几个理由。
fdisk 手动改分区本质上要先把旧分区删掉，再新建一个分区，这依赖分区起始扇区完全一致，一旦起始扇区偏移，数据就全丢了。虽然旧分区和新分区的末尾扇区可以不同，但起始扇区必须严格一致，这对新手来说是个极大的心理负担，稍有不慎就毁掉整块盘。而 growpart 是一个“自动化工具”，它知道如何保留起始扇区，只扩展结束扇区，几乎不可能把分区表搞坏。这是我在生产环境敢用它的核心原因。
resize2fs 和 xfs_growfs 分别对应两种文件系统的专属工具。它们都支持在挂载状态下在线扩容，不需要卸载文件系统，这对生产环境至关重要。如果在扩容过程中要求你卸载 / 分区，基本等于让你停机维护，这在真实环境是无法接受的。
所以这条命令链的设计初衷就是“尽可能少停机、尽可能安全地在线扩容”：磁盘由云平台扩，分区由 growpart 扩，文件系统由原生工具扩，每一步都尽量做到可以回退、可以验证。这也是几乎所有云厂商帮助文档一致推荐的路径。
7. 腾讯云控制台操作细节与常见误区
7.1 控制台扩容的正确入口
登录腾讯云控制台后，路径是：
云服务器 → 实例列表 → 选中实例 → 更多 → 资源调整 → 云硬盘扩容
进去后可以看到当前系统盘容量，输入目标容量，确认订单并支付差价。支付完成后，控制台会显示“调整中”，这个过程结束后才轮到系统内部操作。
这里有一个细节必须强调：系统盘扩容只能升不能降。云硬盘不像服务器内存可以随意减配，系统盘扩容后无法缩回原来的大小。所以在下单前，建议你规划清楚未来2-3年的容量需求，尽量一次扩到位，免得反复扩容多次付费。
另外要注意：系统盘扩容不需要关机，但部分场景下需要重启才能生效。 如果你在控制台看到“调整完成后需重启”，那说明内核可能无法热识别，关掉实例再开机是更快的方式。
7.2 为什么控制台显示扩容成功，但查看不到？——事件日志排查法
在控制台页面，实例详情里有一个“操作日志”或“事件日志”入口，可以查看扩容任务的执行状态。如果一直显示“执行中”，可以等几分钟再刷新。如果显示“失败”，说明底层扩容没成功，需要提交工单。
登录服务器后，用一个命令查看内核日志：
bash复制dmesg | grep -i vda
如果提示有新容量，说明内核已经识别。如果没有任何输出，说明磁盘层可能没生效，这时候先在控制台确认状态，再考虑重启。
7.3 系统盘扩容 vs 数据盘扩容的区别
很多资料会把系统盘和数据盘扩容混着说，实际上两者有一个关键区别：
- 数据盘扩容：大部分情况下可以在线扩容，且不涉及根分区，操作相对简单。
- 系统盘扩容：因为根分区承载了操作系统、系统保留区和临时文件，部分操作需要重启，尤其是老内核环境下，比较容易卡住。
此外系统盘在扩容前往往还需要考虑GRUB引导、initramfs等复杂因素，GPT分区表虽然现代，但部分云平台默认镜像的启动分区（如/boot/efi）结构特殊，扩容时如果改到启动分区相关的MBR区域，可能导致无法启动，所以操作时尽量只动根分区，不要动ESP分区或其他系统保留分区。
7.4 用“新购数据盘+迁移数据”方式替代扩容的适用场景
有一些特殊场景下，我不建议你直接对系统盘扩容，比如：
- 系统盘容量快满，但同时又有迁移上云的需求，此时把关键数据迁到新买的数据盘上，可能更值得。
- 系统已有复杂的LVM结构，或者有多个挂载点，扩容链路长，风险高，此时新购数据盘反而可控性更高。
当然这只是一个权衡方案，如果你只是想“根目录多几个G”，直接扩容还是最省事的路径。
8. 实操案例：从50G扩容到80G的全流程
为了让你更有把握，我贴一份从客户现场复现的完整操作记录。以下是关键输出摘录，敏感信息已脱敏。
第一步：确认环境
bash复制[root@vm-xxx ~]# df -hT
Filesystem Type Size Used Avail Use% Mounted on
/dev/vda1 ext4 50G 30G 17G 64% /
[root@vm-xxx ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
vda 253:0 0 80G 0 disk
└─vda1 253:1 0 50G 0 part /
看到磁盘已经是80G，分区还是50G，非常典型的“等待扩容分区”状态。
第二步：执行 growpart
bash复制[root@vm-xxx ~]# growpart /dev/vda 1
CHANGED: partition=1 start=2048 old: end=104857599 new: end=167772158
第三步：partprobe 刷新
bash复制[root@vm-xxx ~]# partprobe /dev/vda
第四步：执行 resize2fs
bash复制[root@vm-xxx ~]# resize2fs /dev/vda1
resize2fs 1.42.9 (28-Dec-2013)
Filesystem at /dev/vda1 is mounted on /; on-line resizing required
old_desc_blocks = 6, new_desc_blocks = 10
The filesystem on /dev/vda1 is now 20971520 blocks long.
第五步：验证
bash复制[root@vm-xxx ~]# df -hT
Filesystem Type Size Used Avail Use% Mounted on
/dev/vda1 ext4 79G 30G 46G 40% /
完成。整个操作在业务运行状态下完成，耗时不到30秒，无需重启，没有中断业务。
9. 复盘与经验沉淀
可能你会觉得整个流程很“简单”，但越是简单的事情，越容易因为忽略细节而翻车。我把这些年踩过的坑浓缩成几条老实话，写在最后：
第一，云控制台的扩容只是万里长征第一步。 无论腾讯云还是其他平台，扩容系统盘后都必须回到操作系统里面把分区和文件系统扩展到新容量。不要被“控制台显示成功”迷惑，一切以 df -h 的输出为准。
第二，动手之前做快照，不是为了走形式，而是给你的操作留后路。 分区操作属于底层元数据变更，一旦出错，轻则分区表损坏，重则数据全丢。我认识几位圈内运维，因为在测试环境贸然敲了几条命令，结果把整个测试库精准送走。快照是唯一的后悔药。
第三，文件系统类型决定了最后一步的命令。 先看 blkid 再动手，比事后查报错高效得多。ext4 用 resize2fs，xfs 用 xfs_growfs，参数一个是设备路径，一个是挂载点，写错一个就是白忙活。
第四，不要小看 partprobe。 好多人扩容完说 df 没变化，其实是 partprobe 忘了执行，或者分区信息还在内核缓存里挂着。执行完 partprobe 后，记得再用 lsblk 确认分区大小，再决定要不要执行文件系统扩容。
第五，LVM 场景多一步 pvresize。 很多人在LVM环境里直接 lvextend，然后报“no free space”，原因就是PV没有同步扩大。严格按照“分区→PV→LV→文件系统”的顺序，一步都不能跳。
最后说一句掏心窝的话：扩容这件事本身的原理不复杂，真正复杂的是“在真实业务环境下，确保每一步都不打扰正在运行的服务”。只要把握住“分层扩展”的思路，先在控制台扩大磁盘，再在系统里扩分区，最后扩文件系统，你就能从容应对各个云平台，下次再遇到类似问题，根本不用慌。