统信UOS升级后磁盘空间异常减少等问题，源于旧内核、GRUB残留、APT缓存、压缩日志及用户配置未清理；需依次执行内核卸载、APT清空、journal裁剪、用户配置删除及EFI启动项清理。
统信UOS多次系统升级后出现磁盘空间莫名减少、启动器图标复现、应用配置回退或/boot分区告急，根源在于升级过程遗留的旧内核镜像、GRUB菜单项、APT缓存包、压缩日志及用户级临时配置未被自动清除；这些文件分散在/var/cache/apt/archives/、/boot/、/var/log/、~/.cache/等路径，需分层定位并逐项清理。
识别并卸载冗余内核与引导残留
系统升级后保留的旧内核不仅占用/boot数百MB空间，还会在GRUB菜单中生成无效条目，导致开机卡顿或误选崩溃内核。必须先确认当前运行版本，再成对移除旧内核包及对应头文件。
第一步：按Ctrl + Alt + T打开终端，执行uname -r查看当前运行内核，例如输出6.6.35-amd64-desktop；【务必记下该版本，后续操作严禁删除】。
第二步：执行dpkg --list | grep linux-image列出全部已安装内核包，筛选出版本号低于当前且非最新一个（如当前是6.6.35，最新安装为6.6.30，则6.6.25、6.6.18均属冗余）。
第三步：对每个冗余内核执行成对卸载，例如：sudo apt purge linux-image-6.6.25-amd64-desktop linux-headers-6.6.25-amd64-desktop；注意必须同时卸载image与headers，否则/boot中残留initrd.img-*和vmlinuz-*无法被自动清理。
第四步：执行sudo update-grub刷新引导配置，确保GRUB菜单实时同步——若输出中仍显示“Found linux image: /boot/vmlinuz-6.6.25-amd64-desktop”，说明卸载未生效，需检查dpkg状态或跳转至手动清理步骤。
清空APT升级缓存与过期索引
每次apt upgrade都会把新.deb包下载到/var/cache/apt/archives/，而旧包默认不删；连续升级数次后，该目录常堆积1GB以上无用文件，且部分索引可能损坏导致后续更新失败。
执行sudo apt clean，彻底清空/var/cache/apt/archives/下所有.deb文件；这一步安全无副作用，但下次安装软件需重新下载。
执行sudo apt autoclean，仅删除已过期的安装包（即当前源中已不存在对应版本的.deb），保留仍有效的缓存，适合网络较慢时使用。
执行sudo rm -rf /var/lib/apt/lists/* && sudo mkdir -p /var/lib/apt/lists/partial && sudo apt update，重建软件源索引；【若跳过mkdir -p partial，apt update会报错退出】。
粉碎式清理升级产生的压缩日志与临时文件
系统升级过程中，journalctl会自动生成大量.gz压缩日志，存于/var/log/，图形化工具通常忽略它们；单个压缩包可达100MB以上，且长期不清理会拖慢日志查询速度。
方法一：直接删除全部压缩日志
执行sudo rm -f /var/log/*.gz，该命令瞬时释放数百MB，不影响系统运行。
方法二：限制journal总大小并裁剪最旧条目
执行sudo journalctl --vacuum-size=50M，强制将全部journal日志压缩归档后控制在50MB以内；此操作比单纯删.gz更彻底，连带清理未压缩的旧条目。
方法三：清空临时升级残留目录
执行sudo rm -rf /var/tmp/* /tmp/*；注意/tmp下可能有正在运行进程创建的临时文件，若提示“device busy”，可跳过或重启后立即执行。
手动清除用户级升级残留配置
某些应用（如DDE桌面组件、系统监视器、字体管理器）在UOS大版本升级后会生成新配置目录，但旧版配置仍保留在~/.config/下，导致界面错乱或功能异常；这些文件不会被任何apt命令触达，必须人工干预。
进入主目录：cd ~。
执行ls -la .config/ | grep -E "(dde|uos|systemd|gtk)"，快速筛查疑似升级残留的配置组。
对确认不再需要的旧配置目录执行删除，例如：rm -rf .config/dde-daemon-old/ .config/uos-launcher-backup/；【切勿删除.dconf或.user-dirs.dirs，否则桌面布局将重置】。
清空缩略图缓存：rm -rf .thumbnails/*；升级后旧缩略图常因格式变更失效，占空间且无用。
挂载并清理EFI分区中的升级残留启动项
UOS升级若涉及UEFI固件层变动（如从5.x升至6.x），旧版grubx64.efi可能仍注册在主板NVRAM中，导致开机出现“BootOrder: 000A, 0003, 0001”类冗余选项，甚至卡在无效菜单。
第一步：执行sudo efibootmgr -v，查找含“uos-5.15”“deepin-20”或明显旧版本号的BootXXXX行，记下编号（如Boot0007）。
第二步：确认EFI分区设备名：sudo fdisk -l | grep "EFI System"，典型输出为/dev/nvme0n1p1；若无结果，改用sudo blkid | grep vfat筛选含EFI标签的分区。
第三步：挂载并进入EFI目录：sudo mkdir -p /mnt/efi && sudo mount /dev/nvme0n1p1 /mnt/efi && cd /mnt/efi/EFI。
第四步：执行ls，找到与efibootmgr中描述匹配的目录（如Boot0007对应HD(1,GPT,)/File(\EFI\uos-5.15\grubx64.efi)，则目标目录为uos-5.15）；【严格核对名称，误删uos主目录将导致系统无法启动】。
第五步：删除目录：sudo rm -rf uos-5.15 → 执行sudo efibootmgr -b 0007 -B从NVRAM物理清除启动条目。
