企业官网建设流程全解析

1. 先翻垃圾再谈扩容：5分钟定位UOS系统盘的真实占用

1.1 三个命令加一个图形工具，判断"真满"还是"虚满"

接到"统信UOS系统盘空间不足"这个问题，我第一反应从来不是打开分区工具去拉根分区，而是先让对方给我三行命令的输出。df -h看整体使用率，du -sh /home/* 2>/dev/null | sort -rh | head -20看用户目录下的重量级选手，du -sh /var/cache/apt/archives /var/log /var/tmp /opt /usr 2>/dev/null | sort -rh看系统层面的临时数据囤积情况。

为什么一定要先做这步？因为在我处理过的UOS盘满案例里，至少有三成根本不需要扩容，属于典型的"假满"——分区容量本身够大，纯粹是被垃圾文件、旧内核、缓存日志把空间吃干净了。这时候你辛辛苦苦做一个Live启动盘去调分区，折腾一小时，结果发现清理完/var/cache/apt/archives和旧日志之后，可用空间从2GB变成了40GB，分区调整白做了。

图形化工具方面，UOS软件中心里可以直接装一个叫"磁盘使用分析器"的软件（包名是baobab），打开选扫描根目录 /，它会把整个磁盘按目录画成一个个色块，鼠标挪上去就能看到具体哪个文件夹占了几个G。这个工具的直观程度远超命令行，特别适合给刚上手UOS的用户排查问题用。

1.2 常见的"隐形磁盘杀手"：apt缓存、日志、聊天数据占多少心里要有数

统信UOS基于Debian系生态，软件包管理走的是apt那套，所以它天然继承了一些"Debian式空间杀手"。我列一下最常撞见的几个：

• apt软件包缓存：路径在/var/cache/apt/archives，装过的软件包、升级时下载的deb全家桶都留在这里。一台用了半年、装装删删的机器，这里堆到5～10GB非常正常。清理命令是sudo apt clean（清掉所有缓存）或sudo apt autoclean（只清已无用旧版本），区别在于前者把下载目录清空，后者保留最新版本，我一般推荐后者，万一要重装某个软件还能省一次下载。
• 系统日志：journald的日志默认存在/var/log/journal里。journalctl --disk-usage可以查看占用，发现日志几十上百MB属正常，但要是某天发现占了几个G，多半是某个服务在刷屏报错。用sudo journalctl --vacuum-size=200M可以把日志体积压缩到200MB以内，不用重启，亚克西。
• 旧版内核：UOS每次系统更新都会带新内核，老内核的linux-image-*包不会自动卸载，每个旧内核大约占200～400MB，攒三四个就上G了。dpkg --list | grep linux-image看有哪些，保留当前使用的那个，其余用sudo apt autoremove --purge一起干掉。
• 聊天软件和浏览器缓存：很多UOS用户装的是deepin-wine版微信、QQ，它们的聊天图片、文件缓存散落在~/.deepinwine和~/.wine里，动辄数个GB。浏览器的~/.cache目录、下载目录长期不清理，也是一大块。这些位置用baobab一扫就现原形。

这波检查做下来，少则释放3～5GB，多则10GB往上。所以我才坚持说，扩容前先翻垃圾，这五分钟花得不冤。

1.3 什么情况才值得动分区：我的扩容判定标准

清理完之后再跑一次df -h，如果根分区可用空间依然低于总容量的15%～20%，或者你已经预见到未来要继续装大型软件、生产数据还会增长，那才真正到了要动分区表的时候。

我自己的判定标准就两条，满足任意一条就别犹豫：

1. 清理完垃圾后，根分区剩余空间小于5GB，且接下来要装的软件/数据明显大于这个数；
2. SSD整盘容量本来就小（比如128GB的固态），根分区规划时给得太抠，日常使用持续处在"勉强够用"状态。

还有一种情况是物理盘只剩一个分区，系统、数据、软件全挤在一起，这时候扩容一个根分区等于给整盘解压，效果非常明显。反之如果/home已经独立分出去了，根分区还是爆满，那就得想想是不是软件装太多，或者/opt、/usr/local底下有大块头——这种情况单纯扩根分区治标不治本，我更倾向于把大块头迁走，这个后面专门用一节讲。

2. 动手扩容前必须想清楚的三件事：备份、分区识别与为什么不能在线操作

2.1 不必整盘克隆，但这两样一定不能省

很多人一听要动分区表就紧张，觉得必须全盘备份。其实在图形化工具操作得当、又不删分区的情况下，风险没那么可怕，但该做的保险还是得做。我的经验是两样东西必须留：一是重要的个人数据，二是当前系统的分区表信息。

个人数据每个人情况不同，不展开了。分区表信息这个很多人会忽略，我强烈建议在扩容前先把sudo fdisk -l和sudo blkid的输出存到另一个盘或者手机里。为什么？因为万一扩容过程出意外导致分区表损坏，你手里有原始的分区起始扇区号、大小、UUID，恢复起来方向明确得多，不用靠猜。blkid输出的UUID尤其关键，因为GRUB引导和/etc/fstab都靠UUID找分区，一旦UUID变了，系统直接起不来。

2.2 看懂统信UOS的分区布局：EFI、根分区、swap哪个是哪个

动刀之前，得先认识一下UOS默认装出来的分区结构。绝大多数桌面版安装的布局是酱紫的：

也有少数安装场景会单独划一个/boot（大约1GB），或者把/home独立出来，但不管怎么分，核心思路一样：你要扩的是那个ext4格式、挂载点为/的根分区。

怎么确认哪个是根分区？打开"磁盘"工具（gnome-disk-utility），左侧选中你的内置硬盘，右侧看到挂着/的那个分区就是。命令行下跑lsblk -f也能看到，挂载点那一列写着/的清清楚楚。这里提醒一句，如果机器上有两块硬盘，启动时UOS默认从哪块引导、根分区在哪个物理盘上，看lsblk输出的盘符顺序不一定靠得住，还是以挂载点为准最保险。

2.3 为什么挂载中的分区动不了：文件系统层的硬约束

这可能是很多人第一次在系统运行状态下手动调整分区时碰到的困惑：GParted打开了，右键根分区，发现"Resize/Move"是灰色的，点不了。

原因不复杂：ext4文件系统在被挂载使用时，内核不允许对它的块设备进行在线裁剪或移动的底层操作。GParted也没办法绕过这个限制，因为根分区正承载着当前整个系统的运行，你不可能一边开着系统一边把它正在读写的文件系统拆了重组。所以图形化扩容的第一步永远是：从Live环境启动，让目标分区处于未挂载状态。

有些人会想，那我用命令行resize2fs在线扩呢？在特定条件下，ext4确实支持在线扩大（resize2fs可以在挂载状态下扩，配合growpart之类的工具），但图形化工具GParted不会走这条路径，它为了稳妥，坚持要求分区未挂载。而且在线扩只适用于"分区表里现成有未分配空间且刚好在根分区后面"的场景，绝大多数UOS用户的盘并不满足这个条件，因为空闲空间往往在swap后面，或者干脆没有——所以老老实实走Live环境，是通用性最强、对新手最友好的方案。

3. GParted图形化扩容全流程：从制作Live盘到应用分区变更

3.1 制作一个能进图形环境的启动盘：UOS ISO+优盘就够

标题说5分钟搞定，说的就是实际操作这个过程，前提是你手里已经有一个Linux Live启动盘。做启动盘的工具很多，手头是Windows就下个Rufus或者傲梅分区助手，macOS可以用Etcher，最省事的其实是UOS官方自带的"启动盘制作工具"——拿一个8GB以上的空U盘，插入一台正常的UOS机器，打开工具选择UOS的ISO镜像，点制作，几分钟完事。

为什么推荐用UOS本身的ISO做Live环境，而不是找别的Linux发行版？主要是两点：一是UOS的Live环境自带中文字体和DDE桌面，操作界面跟你平时用的系统一致，不容易懵；二是它的Live环境里通常已经预装了GParted，或者打开软件中心装一下也很快（Live环境的源是配好的）。如果手头实在没UOS镜像，随便一个Ubuntu/Debian系的Live盘也行，反正GParted这个工具在各大发行版里都是一等公民，sudo apt install gparted装一下就好。

制作好启动盘之后，建议顺手再往U盘里存一份刚才导出的分区表信息文本，以及如果你有重要小文件的话也备份一份到U盘。这样U盘既是启动介质又是数据保险箱，一个盘解决两件事。

从U盘启动的通用方法是开机时猛按启动菜单键（UOS机器常见的有F12、F7、Del，品牌不同略有差异），在启动设备列表里选带USB字样的那一项，进入后选择"Live系统"或者"试用系统"，等桌面加载完，先别急着操作，开个终端确认一下：lsblk，看清楚哪块是硬盘、哪块是U盘，防止接下来在GParted里选错设备——这个错误一旦犯下，后果不是扩容失败，而是把数据全清空，务必小心。

3.2 GParted拖拽调整根分区：一步步实操记录

进入Live桌面后打开GParted，看到界面上方有个设备下拉框，先确认选中的是你的内置硬盘而不是U盘。然后看图说话：

1. 找到根分区，如果根分区右侧紧挨着的是swap分区，说明空闲空间在swap后面，直接扩根分区是够不着的。这种情况就是我在第6章要展开讲的"swap挡路"问题，先跳到6.1把swap处理掉，再回来继续下面的步骤。
2. 假设情况顺利，比如swap在根分区左侧，或者根分区右侧直接就是未分配空间，那就简单了：右键根分区，选"Resize/Move"。
3. 弹出的窗口里有个条形图，左边代表分区起点，右边代表终点，中间是分区本体。你要做的是把右侧的拖拽手柄往右拉，把未分配空间划进根分区，或者在"New size"输入框里直接输入想要的最终大小（单位是MiB，1GiB约等于1024MiB）。
4. 点"Resize/Move"确认后，GParted界面下方会多出一条"待执行操作"。注意，这个时候其实还没动盘，只是把计划写在了队列里。你可以反复调整，直到满意为止。
5. 确认无误后，点工具栏上的绿色对勾"Apply All Operations"，GParted会弹出一个确认框，一句一句告诉你接下来要执行哪些动作。点Apply，开始跑进度条。

进度条跑的过程，GParted做的事情分两阶段：先移动/缩小分区（如果有这个需求），再调整分区内部的ext4文件系统大小。前者是纯磁盘级的操作，跟里面有啥文件无关；后者才是真正把文件系统撑大的动作，说白了就是扩展ext4的块组结构。对机械硬盘来说这个过程像点钞机一样哗啦哗啦慢跑，可能是全场最耗时的一步；SSD就快得多，几十G的根分区从扩到应用变更，往往也就一两分钟。

跑完之后GParted会提示"All operations successfully completed"，这时候点"Close"，整个逻辑上的扩容就结束了。

3.3 不同分区布局的操作差异：free space 在根分区前后是完全不同的玩法

上面讲的是理想情况，实际动手时你会遇到几种不同的分区布局，每种的处理思路不一样，我汇总一下：

布局A：未分配空间就在根分区右边。最常见也最省事，直接拖拽根分区右边界，10秒完成规划，应用变更时只需等待文件系统扩展，速度最快。

布局B：swap在根分区右边，未分配空间在swap右边。你要扩根分区的话，得先把swap"搬家"——右键swap选Resize/Move，在整个条形图上把swap整体向右拖，让它在最右边，腾出来的空位留给根分区。这一步会发生数据移动，耗时取决于swap和中间空挡的大小，通常也就几分钟，只是机械盘上会多等一会。

布局C：/home独立分区，且在根分区间插在中间、后面是空闲空间。如果需要给根分区扩容，本质是把/home的起始位置向右移动，相当于整个home分区"平移"，这步操作时间最久，移动大量数据时耗时可能以小时计（几百GB的home在机械盘上真能跑两三个小时）。所以布局C下我通常会反过来想：要不要干脆把/home缩一点、省出空间来？缩home比移动整个home快得多，风险也小。

布局D：LVM逻辑卷。某些用户安装时选了LVM，这时lsblk看到的不是一个简单ext4分区，而是/dev/mapper/xxx-root之类的逻辑卷。LVM的好处是可以在系统运行状态下在线扩容，甚至不需要Live盘：sudo lvextend -l +100%FREE /dev/mapper/xxx-root之后，再sudo resize2fs /dev/mapper/xxx-root就完事。但前提是卷组里有未分配空间，如果没有，还是得先用GParted把物理分区扩大，再回来扩逻辑卷。判断方法看lsblk里有没有└─开头的层级结构，有就是LVM。

4. 扩容完成后的验证与启动修复：最后两步别省略

4.1 重启前在Live环境里确认的四个检查项

很多人操作完GParted一激动直接重启，结果卡在GRUB界面或者黑屏，才开始后悔没多看一眼。我的习惯是重启前在Live环境里做四个检查，每一步都不超过半分钟：

1. 重新跑一遍lsblk -f，确认根分区的新大小、UUID跟扩容前一致、文件系统类型还是ext4。UUID基本不会变，但看一眼图个安心，同时确认没有多余的残留分区。
2. 挂载根分区，验证文件系统可读。在Live环境里执行sudo mount /dev/nvme0n1p2 /mnt，然后cd /mnt && ls或者跑个sudo fsck -f /dev/nvme0n1p2。这步能提前过滤掉文件系统层面的问题。注意fsck检测前先umount卸载，避免对已挂载分区检查产生干扰。
3. 检查 /mnt/etc/fstab 和 /mnt/boot/grub仍在原处，内容看着正常。fstab里记录的根分区UUID如果和blkid输出一致，引导基本不会跑偏。
4. 确认swap分区还在且类型正确。如果刚才动过swap，看一眼sudo swapon --show在Live环境里能否正常启用它（不启用也行，关键是分区类型没被搞坏）。

四项全过，再拔U盘重启。很多人会觉得fsck这步多余，但我要说，分区调整是块设备级别的操作，万一执行到一半断电或者系统崩溃，文件系统元数据是有可能处于非一致状态的，启动前让fsck把结构纠正一遍，能避免后续一连串奇奇怪怪的问题。

4.2 重启起不来的常见原因：GRUB与EFI引导的图形化修复

重启后如果看到GRUB命令行黑屏，或者干脆提示找不到启动设备，先别慌。绝大多数情况不是数据丢了，而是引导链路上某个环节因为分区变化受到了影响。我遇到过的场景主要有两种：

第一种是扩容后EFI分区本身没动，但主板启动顺序发生了错乱。这通常在BIOS设置里能直接解决，进固件设置界面，把UEFI引导顺序里对应系统盘的那一项重新置顶就行，界面全是中文，挨个看下来不费劲。

第二种是GRUB配置丢失或损坏。这种需要借助Live盘进系统后用工具修复，UOS系统本身带图形化修复工具，与很多人想的完全不同——不需要你在黑屏命令行里手敲grub-install。具体做法：Live系统启动后，用文件管理器把内置硬盘的根分区挂载上（UOS桌面会自动挂载，点一下盘符就行），然后打开终端执行重装GRUB到EFI分区的命令，核心是sudo mount /dev/nvme0n1p2 /mnt、sudo mount /dev/nvme0n1p1 /mnt/boot/efi，再用chroot进入系统环境执行grub修复命令。命令看着多，但按顺序敲就好，网上UOS引导修复的教程一搜一大把，我不赘述具体命令了，只想强调：分区扩容一般不会破坏GRUB文件本身，多是EFI启动项指向了旧的分区UUID记录，重新生成一次启动配置就恢复。

5. 实在不想动刀的情况下：几条缓解系统盘压力的替代方案

5.1 把home或其他大目录迁到独立分区或外置盘

如果看了前几章还是觉得动分区表风险大，或者手头没有空闲空间可挪用，那么把根分区里的大目录整体搬迁到另一个分区，是性价比非常高的折中方案。

最常见的是迁/home。假设机器里有一块数据盘或者已经存在一个独立分区挂载在比如/data下，那操作思路是：把当前用户目录的内容复制过去，然后改挂载关系，让/home指向新位置。UOS桌面环境对用户目录的缓存和配置非常敏感，迁完以后登录桌面前十秒可能慢一点，那是它在加载缓存，属正常。

具体到图形化操作，可以用文件管理器直接复制粘贴目录，再把分区挂载点改掉；但这里有一个大坑我必须提醒：复制的时候要用保留权限的方式，文件管理器右键复制粘贴出来的目录，属主和权限往往变成了当前登录用户，等换回系统登录时,你可能会遇到一个"家目录找不到"的诡异状态。稳妥的办法是用终端sudo cp -a /home/user /目标目录/，-a参数会保留下属主、权限、时间戳等一切属性。复制完成后改/etc/fstab，把对应分区的挂载点从/data改成/home，或者用命令行bind mount，重启一次验证。

5.2 移动硬盘/U盘临时顶上：适合短期扩容现场

如果你的场景是"最近有一批大文件要处理，但系统盘容量告急，又不想马上扩容"，那最简单的方式就是接一块移动硬盘或者大容量U盘，直接把大文件往里扔。"移动硬盘做系统盘""U盘变成系统盘"这类玩法在热词里也很火，但那是另一个话题，我这里说的是作为数据盘来用。

操作系统层面对这种外置盘的接管非常自然，插上后在文件管理器里就能看到，往里面写文件就行了。想让它更"系统化"一些，可以把外置盘的一个分区手动挂载到固定目录，比如/mnt/big，然后把你日常产生的大数据文件路径指过去。不少下载工具、备份工具（比如网盘客户端的下载目录）都可以在设置里改存储路径，改到外置盘，系统盘压力瞬间消失。

实测下来的经验是：这种方案适合临时顶3～6个月，长期用的话外置盘的稳定性、速度都远不如内置盘，供电不稳的U盘还可能掉盘，重要数据放里面风险偏高。

5.3 日常空间保养：日志、缓存、镜像的定期清理节奏

与其等到满了再扩容，不如养成习惯。我在帮人维护UOS机器时，会顺手搭一个简单的"空间保养节奏"，效果比任何扩容都持久：

• 每周：sudo journalctl --vacuum-size=200M，控制日志总量。
• 每月：sudo apt update && sudo apt upgrade之后随手sudo apt autoclean && sudo apt autoremove，清掉升级残留的deb包和旧依赖。
• 每季度：用baobab扫一遍根目录，看看有没有异常膨胀的目录，该删的删，该迁的迁。
• 每次下载大文件后：确认下载目录里有没有重复的、不再需要的安装包ISO，直接清掉。

另外UOS自带的"系统清理"工具在控制中心里也有，主要清的是回收站、壁纸缓存、软件缓存这类表层垃圾，日常点一下也算方便。这些习惯养成了，500G系统盘三年不扩容也没问题，反而是那些配了1T却从不清理的机器，照样会满——空间不足这件事，容量只是其一，管理才是根本。

6. 扩容翻车现场复盘：我踩过的坑和现在的习惯

6.1 swap挡在根分区后面时：先把swap挪走再扩

我第一次给UOS扩容，就栽在swap上。当时系统是默认安装的，根分区右侧紧贴着swap，swap再往右倒是有几十GB空闲，但GParted里怎么拖根分区右边界都拖不过swap那一格。那会儿我还不熟悉分区移动的逻辑，反复试了几次，最后才明白：必须先右键swap，选Resize/Move，把swap整体向右拖到最右端，让它在磁盘上"让路"，根分区才有空间向右扩展。

这个操作的原理不复杂：分区表的调整按扇区序号来，根分区要变大，右边必须连续地有未分配空间，swap夹在中间就相当于一堵墙，得先把墙挪走。挪swap的时候，GParted会先把swap分区里的数据读出来写到新位置，再更新分区表，所以耗时跟swap大小和硬盘速度挂钩，2到8G的swap走个几分钟很正常。操作完之后记得顺手把swap分区的UUID记录一下——如果系统里/etc/fstab和GRUB配置引用了swap的UUID，移动分区位置其实不会改UUID，但多个心眼总没错。

6.2 文件系统检查和resize的先后顺序：图形工具没明说的细节

GParted在应用Resize操作时，会自己先做一遍文件系统检查，再把ext4分区大小应用到文件系统上，所以你手动点Apply的时候不用额外跑fsck。但有一个场景例外：如果之前系统曾经非正常关机，文件系统标记为脏状态，GParted可能在中途卡住或者提示需要前置检查。我的经验是，遇到这种情况先在Live终端的umount状态下跑一遍sudo e2fsck -f /dev/根分区，把文件系统彻底检查理顺了，再回到GParted里做Resize，操作会流畅非常多。

还有一个顺序细节：先扩分区，再扩文件系统。在GParted界面里，你拖拽分区大小后点Apply，它内部会按"调整分区表→扩展文件系统"的顺序自动完成，用户不用干预。但如果你是在命令行手动操作，比如配合LVM的场景，那就必须严格按"先分区（growpart或lvextend）、后文件系统（resize2fs）"的顺序来。搞反了的话，文件系统以为自己的块数没变，但分区表已经给它划了更大的地盘，这种不一致状态虽然多数时候能事后补救（再跑一次resize2fs就行），但没必要自找麻烦。

6.3 扩容到一半断电怎么办：别慌，照着这个顺序救

这条是给最坏情况准备的。假设命不好，GParted进度条跑到一半停电了或者系统卡死强制重启了，重启之后能不能进系统全看运气。我的处理顺序是这样：

1. 不要直接进原系统。用Live盘启动，打开终端，对根分区执行sudo e2fsck -f /dev/根分区。ext4本身有日志，断电后fsck能根据日志把文件系统恢复到一致状态。这个过程可能持续几分钟到十几分钟不等，屏幕上滚动的内容看不懂没关系，等它停下来。
2. fsck通过后，把根分区挂载到/mnt，看看关键目录是否完好。如果能看到正常的etc、usr、home目录结构，大概率已经安全了。
3. 再检查分区表有没有被破坏。sudo fdisk -l看看分区数量、类型跟扩容前是否一致。如果哪个分区消失了，先别急着重新分区覆盖，用testdisk（Live环境里有的话）分析一下，十有八九能恢复原分区表。
4. 确认无误后重启进系统。如果进不去，参照4.2节的引导修复流程处理。

说实话，我自己帮人处理过几次这类故障，断电+扩容的组合拳虽然吓人，但能落到"文件系统脏标记"这个层次的居多，真正全盘崩溃的少。不过这话说出来不是让你放心大胆去赌，而是想告诉你：扩容前那句"重要数据先备份"不是废话，万一真到了需要testdisk恢复文件的境地，有备份的人两分钟完事，没备份的人得对着屏幕哭半天。

回到开头那个问题——统信UOS系统盘空间不足到底怎么办？我的最终建议是：先清理，再规划，最后动手扩容。图形化方案（GParted）是这里面最亲民、门槛最低的路径，按本文第3章的流程走一遍，配合第4章的验证和第6章的避坑经验，绝大多数机器都能顺利完成扩容。做完之后，记得把这篇文章提到的清理习惯落实下去，别让同一个坑绊倒第二次。