Ubuntu 20.04软件安装与软件中心打不开修复指南

1. 先搞清楚Ubuntu 20.04的软件生态为什么总让人头疼

1.1 从一次真实的"软件中心打不开"说起

Ubuntu 20.04这个长期支持版本，装过的人都知道，它属于那种"第一眼看着挺顺手，用几天就开始各种别扭"的系统。我自己前前后后在物理机、虚拟机、云主机上装过不下二十次，最常被问到的问题永远绕不开两个：一是软件到底怎么装才干净，二是左上角那个Ubuntu Software软件中心怎么突然就打不开了，点开转圈、白屏、闪退、提示"无法获取软件列表"，各种姿势都试过还是不行。

这个标题拆开来看，核心其实是三件事：Linux系统这个大前提下，Ubuntu 20.04这个具体版本的软件安装方法，以及软件中心的恢复手段。它解决的不是什么高深的技术难题，而是新手到中级用户最日常、最高频、也最容易被卡住的环节。适合谁来参考？刚把Ubuntu装进虚拟机准备学Linux命令的人、想把日常办公环境从别的系统迁过来的人、需要给团队统一部署Linux开发环境的人，以及那些被软件中心坑过一次、想彻底搞明白apt、snap、dpkg之间关系的人。

很多人第一次接触Ubuntu，习惯性地用图形界面的软件中心去点"安装"，结果要么进度条卡死，要么装完了在终端里找不到命令。这套逻辑跟Windows时代双击exe完全不一样，你得先理解Ubuntu的软件从哪来、由谁管、装到哪去了，后面所有操作才顺理成章。软件中心失灵，本质上也不是它坏了，而是它背后依赖的几个服务没配好或者被"污染"了。

1.2 20.04这个版本的软件管理到底由几套系统在管

Ubuntu 20.04的软件管理是个"多套机制并存"的典型样本，这一点必须先在脑子里理清楚，不然你会觉得特别混乱。它同时存在四层东西：

第一层是apt/dpkg体系，这是最传统、最核心的，所有.deb包的安装、卸载、依赖解析都归它管，/var/lib/dpkg下面记录着系统里所有包的状态。第二层是snap体系，Ubuntu背后公司主推的沙箱化包格式，软件中心里很多应用其实走的是snap通道，安装在/snap目录，跟传统deb包互不干扰。第三层是PPA第三方源，允许你添加个人或团队维护的软件仓库，比如一些较新的驱动或者小众工具。第四层是Flatpak，虽然20.04默认没装，但很多人会自己加上，作为snap的替代或者补充。

这四套东西各自有各自的命令、各自的缓存、各自的依赖数据库。软件中心（Ubuntu Software）在20.04里其实是个snap应用，它同时要跟apt后端和snap后端打交道，任何一端出问题，界面表现就是"打不开"或者"列表空"。这就是为什么单纯重启软件中心没用，因为病根可能在apt源、可能在snapd服务、也可能在网络代理配置上。

我踩过最典型的一个坑：某次在一台内网机器上，apt源指向了一个已经下线的镜像站，结果软件中心打开就崩溃，因为它先跑去拉apt的软件索引，超时后整个界面就挂了。那时候我还没意识到问题出在源上，折腾了半天软件中心本身，纯属浪费时间。

提示：判断问题在哪一层，最快的办法是打开终端，分别跑apt update和snap refresh，哪个报错，软件中心大概率就是被哪个拖垮的。

1.3 装软件之前必须建立的三个认知

在动手之前，有三个认知如果建立了，后面的操作会顺畅很多。

认知一：图形界面是壳，命令行才是里。软件中心能装的东西，命令行几乎都能装，而且命令行给的报错信息详细得多。我现在的习惯是，能用命令行就用命令行，软件中心只作为浏览和发现新软件用。命令行装完的东西，位置、依赖、配置文件在哪，一目了然。

认知二：来源不同，卸载方式就不同。用apt装的用apt remove卸，用snap装的用snap remove卸，用源码编译装的得回到源码目录make uninstall或者手动删。很多人装完软件卸不干净，就是因为装的时候没记来源。我一般会在自己的笔记里记一笔"某年某月某日，用snap装了某软件"，看着啰嗦，但半年后要清理系统时特别省事。

认知三：网络环境决定了你一半的安装体验。Ubuntu默认的源在国外，国内直连慢是常态，这直接导致软件中心转圈、apt下载龟速。把源换成国内镜像，是几乎所有安装问题里性价比最高的一个操作，没有之一。

理解了这三点，我们再来谈具体的安装路径和软件中心的修复，就会顺很多。

2. 四条主流软件安装路径，各自适合什么场景

2.1 apt：最稳的底线方案，先把源配好

apt是Ubuntu上最正统的安装方式，apt install 软件名这条命令能解决80%的安装需求。它的核心逻辑是：系统维护一份软件源列表（在/etc/apt/sources.list和/etc/apt/sources.list.d/里），执行apt update时去这些源拉取软件索引，缓存到本地，然后apt install时根据索引找到包、解析依赖、下载、安装。

Ubuntu 20.04默认的源写的是archive.ubuntu.com这类国外地址，国内用起来经常慢到怀疑人生。换源的标准操作是：

# 先备份原始源文件，这是好习惯，出问题能回滚 sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak # 编辑源文件，把里面的地址替换成国内镜像 sudo nano /etc/apt/sources.list

20.04的代号是focal，替换时要注意源地址里的focal不能写错。常见国内镜像站点的地址结构基本一致，把http://archive.ubuntu.com/ubuntu/这段替换掉就行。改完之后一定要执行：

sudo apt update sudo apt upgrade

update是刷新索引，upgrade是升级已安装的包，两者别搞混。我见过太多人只改源不update，然后抱怨"怎么还是这么慢"，其实索引没刷新，apt还在用旧的缓存地址。

注意：改源的时候不要整行乱改，只替换域名部分，后面的focal、focal-updates、focal-security这些组件名保持原样。改错一个字母，apt update就会报404，反而更麻烦。

apt安装的几个高频命令值得记牢：

操作	命令	说明
更新索引	sudo apt update	只刷新列表，不装东西
安装软件	sudo apt install 包名	自动处理依赖
卸载软件	sudo apt remove 包名	保留配置文件
彻底卸载	sudo apt purge 包名	连配置文件一起删
清理无用依赖	sudo apt autoremove	删掉不再被依赖的包
搜索软件	apt search 关键词	在索引里找包
查看包信息	apt show 包名	看版本、依赖、大小

apt的优点是稳定、依赖处理成熟、卸载干净；缺点是软件版本往往偏旧，因为Ubuntu为了系统稳定性，仓库里的版本会滞后。想要新版本，就得考虑下面几种方式。

2.2 snap：被误解最多的一套机制

snap是Ubuntu主推的包格式，特点是自带依赖（把运行时都打包进去）、沙箱隔离、自动更新。软件中心里很多应用，比如一些开发工具、播放器，默认走的就是snap。

它的好处很明显：不受系统库版本限制，装上去就能跑，更新也自动。但缺点同样突出：因为自带了依赖，包体积巨大，一个简单的软件可能几百兆；启动速度通常比原生deb包慢；权限受沙箱限制，访问外部文件或者硬件时经常需要手动放权。

常用命令：

# 查看已安装的snap snap list # 安装 sudo snap install 软件名 # 卸载 sudo snap remove 软件名 # 刷新所有snap应用 sudo snap refresh # 查看snap服务状态 systemctl status snapd

我实际用下来的感觉是，snap适合那些"装了就图个能用、不想折腾依赖"的场景，比如刚装完系统想快速搞个开发环境。但如果对性能敏感，或者需要深度访问系统资源，还是优先找deb包或者源码编译。

一个特别值得说的点：软件中心在20.04里就是通过snap安装的，包名是snap-store。所以当软件中心出问题时，很大概率是snapd服务或者snap-store本身的问题，后面修复章节会详细讲。

2.3 PPA与Flatpak：小众需求和多源并存

PPA（Personal Package Archive）是让开发者自己维护软件源的机制。当你需要某个软件的较新版本，而官方仓库又没有时，添加对应的PPA是个办法：

# 添加PPA sudo add-apt-repository ppa:作者名/仓库名 sudo apt update sudo apt install 软件名

20.04里add-apt-repository命令需要software-properties-common这个包，如果提示命令找不到，先装它。PPA的坑在于：它不经过Ubuntu官方审核，来源五花八门，添加太多PPA会让apt update越来越慢，还容易引发依赖冲突。我的建议是，只添加你确实需要、且维护活跃的PPA，用完不需要了就删掉。

Flatpak是另一套沙箱格式，跟snap定位类似，但生态更偏向桌面应用。20.04默认没装，需要手动：

sudo apt install flatpak sudo apt install gnome-software-plugin-flatpak flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

装完之后重启，软件中心就能看到Flatpak的应用了。Flatpak和snap的最大区别是它不绑定某个发行版，跨发行版通用性更好。

提示：同时开snap、Flatpak、PPA会导致软件来源极度混乱，同名的应用可能有好几个版本。我的习惯是选定一套主要的，其他只作为补充，不要全都开着。

2.4 源码编译与离线deb：什么时候才真需要

有些软件官方仓库没有、snap也没有、PPA也找不到，那就只能源码编译或者手动装deb包。

源码编译的通用流程是./configure && make && sudo make install，但实际远没有这么顺。依赖缺什么就apt install什么，configure报错基本都是在说缺库。编译出来的东西默认装在/usr/local/下，卸载的时候得回到源码目录执行sudo make uninstall，如果当初没保留源码目录，卸载就成了体力活。

离线deb包的安装用dpkg：

sudo dpkg -i 包名.deb # 如果提示依赖缺失，用这个命令自动补 sudo apt install -f

dpkg -i只负责装，不管依赖，所以经常报依赖错误。报错之后跑一下apt install -f，让apt去把缺的依赖补上，这是标准解法。顺序千万别搞反，先dpkg再apt -f。

源码编译这种方式的经验是：除非真的没有别的选择，否则别用。它带来的维护成本远高于装的时候省的那点事。

3. 软件中心恢复：从诊断到修好的完整流程

3.1 软件中心为什么在20.04里这么容易出问题

要修软件中心，得先明白它在20.04里的结构。20.04的Ubuntu Software其实经历了从传统gnome-software到snap-store的过渡，系统里可能同时存在两个：

• gnome-software：传统的软件中心，主要对接apt和部分插件。
• snap-store：基于snap的新版软件中心，20.04默认界面通常是这个。

两者都可能被叫做"软件中心"，但底层完全不同。用户点开图标看到打不开，得先确认自己点的是哪个。一个简单的判断方法：

# 看系统里装了哪些相关包 snap list | grep store apt list --installed | grep gnome-software

如果snap里有snap-store，那默认图标大概率指向它。这时候问题排查方向就是snap体系；如果只有gnome-software，那排查方向是apt体系。

软件中心打不开的常见表现及对应原因，我整理了一张速查表：

表现	可能原因	排查方向
点开转圈后闪退	snapd服务异常	systemctl status snapd
打开白屏	网络代理或源不通	检查apt源、代理设置
提示无法获取软件列表	索引损坏或源失效	apt update看报错
界面能开但搜不到软件	后端插件缺失	检查各插件包是否安装
一直提示"正在等待"	锁文件占用	检查是否有apt进程在跑

这张表我在团队里分享过，新人照着对号入座，大部分情况五分钟内能定位到方向，比盲试快得多。

3.2 标准修复流程：从轻到重一步步来

修复要遵循"从轻到重"的原则，能重启服务解决的绝不去重装，能重装包解决的绝不去动系统。

第一步，先刷新索引和snap。

sudo apt update sudo snap refresh

这两个命令分别对应两套后端，哪个报错就说明哪一层有问题。很多时候软件中心打不开只是因为索引太旧或者某个snap卡在更新中，刷新一下就好了。

第二步，重启snapd服务。

sudo systemctl restart snapd

snapd是snap的守护进程，软件中心依赖它。这个服务偶尔会卡死，重启后软件中心往往能恢复。

第三步，重置snap-store。

sudo snap remove snap-store sudo snap install snap-store

注意，remove再install等于重装，配置会丢，但应用数据一般还在。这是修复软件中心最有效的一招，我用它救回过好几台机器。

第四步，修复gnome-software（如果是它在闹）。

sudo apt install --reinstall gnome-software sudo apt install --reinstall gnome-software-plugin-snap

--reinstall是重新安装同一个包，不升级版本，专门用来修复文件损坏。

第五步，清理缓存。

sudo rm -rf /var/cache/apt/archives/* sudo apt clean sudo apt update

缓存损坏也会导致界面异常，清掉重建是最省事的办法。

整个流程走完，90%以上的软件中心问题都能解决。如果还不行，那基本是网络或者代理层面的问题，得往下看。

3.3 网络与代理是隐藏最深的那个坑

软件中心一个特别让人抓狂的点是：它比命令行更容易受代理影响。如果你给系统配了代理，命令行里通过环境变量能生效，但软件中心的图形界面不一定读取同样的环境变量，结果就是终端能apt update，软件中心却打不开。

20.04里代理配置有几个位置：

• 系统设置里的网络代理（GNOME设置）。
• /etc/apt/apt.conf.d/下的apt代理配置。
• shell里的http_proxy、https_proxy环境变量。
• snap自己的代理配置（snap set system proxy.http=...）。

这几处如果不一致，就会出现"命令行正常、界面抽风"的诡异现象。排查办法是先把所有代理配置统一，或者干脆临时全部关掉，看软件中心能否恢复：

# 查看当前环境变量里的代理 env | grep -i proxy # 查看apt的代理配置 grep -ri proxy /etc/apt/apt.conf.d/

如果确认是代理导致，最干净的做法是在系统设置里把代理配好，让图形界面和命令行用同一套。内网环境尤其要注意这一点，我遇到过团队里好几台机器都是因为代理只配了命令行，导致软件中心长期不可用，大家还以为系统坏了。

还有一种情况是DNS解析问题。如果源域名解析不了，apt update会提示"无法解析"，软件中心同样开不了。解决办法是检查/etc/resolv.conf，或者临时换个可用的DNS测试。这类问题在内网和虚拟机里很常见。

3.4 一套可以反复用的自检脚本

修多了之后，我把常用的自检命令拼成了一个小脚本，每次遇到软件中心问题先跑一遍，几秒钟就能看出病根在哪：

#!/bin/bash echo "===== 1. 检查apt索引 =====" sudo apt update 2>&1 | tail -5 echo "===== 2. 检查snapd状态 =====" systemctl is-active snapd echo "===== 3. 检查snap-store是否安装 =====" snap list | grep snap-store echo "===== 4. 检查网络连通性 =====" ping -c 2 archive.ubuntu.com echo "===== 5. 检查是否有apt锁 =====" sudo lsof /var/lib/dpkg/lock-frontend 2>/dev/null || echo "无锁占用" echo "===== 6. 检查代理设置 =====" env | grep -i proxy || echo "无代理环境变量"

这个脚本不算复杂，但它把排查的顺序固化了，不会漏检查某一项。团队里推广之后，新人遇到问题先跑脚本，报错截图发出来，基本一眼就能定位。这种"把经验固化成脚本"的做法，比写一堆文档管用得多，因为脚本不会因为别人没看文档而失效。

注意：脚本里的sudo命令在跑的时候会要密码，如果是在自动化场景里用，要考虑改成免密或者调整权限，不要直接把带sudo的脚本丢进定时任务。

4. 装软件时踩过的坑与排查实录

4.1 锁文件、依赖冲突与dpkg中断

linux装软件最经典的两个报错，一个是"无法获得锁 /var/lib/dpkg/lock-frontend"，另一个是"dpkg被中断，必须运行sudo dpkg --configure -a"。

锁文件问题：apt在同一时间只允许一个进程操作，如果你开了两个终端，一个在apt install，另一个也在装东西，第二个就会报锁。还有一种情况是上一次apt进程异常退出，锁没释放。解决办法是先确认没有apt进程在跑：

ps aux | grep -i apt

确认没有之后，删掉锁文件：

sudo rm /var/lib/dpkg/lock-frontend sudo rm /var/lib/dpkg/lock sudo rm /var/cache/apt/archives/lock

删锁这事有点"暴力"，但确实是标准解法，前提是确认没有正在运行的安装进程，否则会搞坏数据库。

dpkg中断问题：安装过程中断电、强制关机、或者手动kill掉dpkg，都会导致它处于"中断"状态，后续任何apt操作都失败。修复命令就是它提示的那条：

sudo dpkg --configure -a sudo apt install -f

这条命令会把还没配置完的包重新配置一遍，把依赖补全。我遇到过一次虚拟机装软件时宿主强制关机，重启后dpkg就中断了，跑这两条命令立刻恢复，不用重装系统。

依赖冲突：多见于添加了多个PPA之后，不同源提供同一个包的不同版本，apt解析不出来。解决办法是逐个禁用PPA排查：

sudo add-apt-repository --remove ppa:xxx/yyy

或者用aptitude工具，它在处理冲突时给出的方案比apt更多：

sudo apt install aptitude sudo aptitude install 包名

aptitude会给出接受/拒绝的交互式选项，能一步步逼近可行解，比apt直接撂挑子强。

4.2 中文环境相关的软件安装要点

Ubuntu 20.04的中文环境安装有一堆琐碎但绕不开的点，尤其是输入法和字体，装不好直接影响使用体验。

中文输入法：20.04默认用的输入法框架是fcitx或ibus。以fcitx为例，标准安装流程：

sudo apt install fcitx fcitx-googlepinyin fcitx-config-gtk

装完要在"语言支持"里把输入法框架切到fcitx，然后重启会话，再在fcitx配置里添加拼音。很多人装完发现切不出来，基本都是忘了切换输入法框架，或者没重启会话。这个问题在虚拟机里尤其常见，因为虚拟机的键盘映射有时会和宿主机冲突。

中文字体：默认字体在中文显示上还可以，但如果要更接近macOS那种渲染效果，可以装一些额外字体，然后在GNOME Tweaks里调整字体设置和抗锯齿。这个属于个人偏好，但装了之后确实观感提升明显。

中文乱码：linux 解压文件乱码是个高频搜索词，尤其是从Windows传过来的zip压缩包，解压后中文文件名变成乱码。原因是Windows的zip用的是GBK编码，而Linux默认用UTF-8。解决办法是用unzip指定编码：

unzip -O GBK 文件名.zip

如果unzip版本太老不支持-O，可以装p7zip用7z解压，或者用convmv转换文件名编码。这个坑几乎每个从Windows迁移过来的人都踩过，知道原因之后就一句话的事。

4.3 权限管理与sudo的正确使用姿势

Linux的权限模型是新手最大的门槛。装软件为什么非要sudo？因为安装要往/usr、/etc这些只有root能写的目录里塞东西。理解这个之后，很多"为什么提示权限不够"的问题就通了。

什么时候需要sudo：涉及系统目录写入、服务管理、系统级配置更改时需要；在用户目录下操作文件、跑用户级命令时不需要。我见过新人图省事，把所有命令都加sudo，结果在用户目录里生成了一堆root所有权的文件，之后用普通用户反而改不动了，还得chown修回来。

怎么改文件所有权：

sudo chown -R 用户名:用户名 目录名

-R递归，改目录下所有文件。这个命令救过我很多次，尤其是误用sudo编辑了用户配置文件之后。

环境变量的问题：ubuntu环境变量配置错误也是高频问题。环境变量配错会导致命令找不到、软件启动失败。常见的是修改~/.bashrc或/etc/profile时写错路径。出错之后如果连终端命令都不好使了，可以用绝对路径启动命令，或者临时把PATH修正回来：

export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

这条把PATH重置成默认值，能救急。改环境变量之前一定要先备份文件，这是血泪教训。

提示：改/etc/profile或~/.bashrc这种影响全局的文件时，改完先别关当前终端，开一个新终端测试，确认没问题再关旧的。这样万一改坏了，还能从旧终端里把文件改回来。

4.4 常见问题速查表

把我在实际使用中遇到的高频问题汇总成一张表，方便对照排查：

问题现象	可能原因	解决命令
无法获得锁	有apt进程占用	ps aux | grep apt后删锁文件
dpkg被中断	上次安装未完成	sudo dpkg --configure -a
命令找不到	包未装或PATH问题	apt install或检查PATH
依赖缺失	源不完整或PPA冲突	sudo apt install -f
软件中心打不开	snapd异常或索引损坏	刷新snap、重置snap-store
解压中文乱码	编码不一致	unzip -O GBK
输入法切不出来	框架没切换	语言支持里改framework
环境变量失效	配置文件写错	备份后修正，重置PATH

这张表的用法是"先看现象，再找原因，最后执行命令"，三步走。新手最容易犯的错是跳过"找原因"直接乱试命令，结果把小问题搞成大问题。养成先看报错、再对症下药的习惯，比背命令重要得多。

5. 把软件环境管起来，让问题越来越少

5.1 记录来源与定期清理

软件装得越多，环境越乱。真正让系统长期稳定的办法不是装的时候多小心，而是装完就记。

我现在在每台常用机器上维护一个简单的清单文件，放在~/notes/software.md，装任何非apt默认源的东西都记一笔：装了啥、什么时候装的、用什么方式装的、干嘛用的。看着像多此一举，但半年后想清理系统时，你会发现这份清单是唯一能告诉你"这个包能不能删"的依据。没有它，面对snap list里一堆不认识的名字，只能靠猜。

定期清理的几条命令：

# 清理不再需要的依赖 sudo apt autoremove # 清理apt缓存 sudo apt clean # 查看占用最大的snap du -sh /snap/* | sort -rh | head # 查看已禁用的snap（占空间但没在跑） snap list --all | grep disabled

禁用版本的snap会一直留在磁盘上占空间，可以用snap remove --revision=版本号 包名删掉。这个细节很少有人提，但磁盘紧张的时候特别管用。

5.2 版本锁定与升级的分寸感

Ubuntu 20.04是个LTS版本，支持周期长，但仓库里的软件版本偏旧。要不要升级某个软件，得看具体情况。

可以放心用仓库版本的：系统工具、编译器等基础组件。这些动了容易引发连锁反应。

需要手动升级的：开发工具、浏览器、一些更新频繁的应用。可以通过PPA或者官方提供的deb包。

锁定版本的方法：

# 禁止某个包被自动升级 sudo apt-mark hold 包名 # 解除锁定 sudo apt-mark unhold 包名 # 查看已锁定的包 apt-mark showhold

这个功能在维护生产环境时特别有用。有些软件升级后会改配置、改行为，自动升级可能直接把服务搞挂。锁定之后等你测试好再手动升，节奏自己掌握。

我个人的习惯是：开发机保持常规更新，但关键工具锁定；服务器上除了安全更新，其他一律锁定，升级走测试流程。这个分寸感是踩了几次"升级之后服务起不来"的坑之后慢慢磨出来的。

5.3 一套命令速查，放在手边随时用

最后把我自己常用的一组命令整理出来，装软件、修软件中心、排查问题基本都覆盖了：

# ===== 源与索引 ===== sudo apt update # 刷新索引 sudo apt upgrade # 升级已装包 sudo apt full-upgrade # 允许删包来完成升级 cat /etc/apt/sources.list # 查看源配置 # ===== 安装与卸载 ===== sudo apt install 包名 sudo apt remove 包名 sudo apt purge 包名 # 连配置一起删 sudo apt install -f # 修复依赖 # ===== snap相关 ===== snap list sudo snap install 包名 sudo snap remove 包名 sudo snap refresh systemctl restart snapd # ===== 修复软件中心 ===== sudo snap remove snap-store && sudo snap install snap-store sudo apt install --reinstall gnome-software # ===== 排查 ===== ps aux | grep apt sudo lsof /var/lib/dpkg/lock-frontend env | grep -i proxy ping -c 2 archive.ubuntu.com

这套命令不是让你背，而是让你在遇到问题时知道该往哪个方向找。命令可以查，思路得自己有条理。

关于软件中心修复，我最后再分享一个小经验：如果snap remove snap-store之后snap install snap-store一直卡着装不上，别急着怀疑系统坏了，先看看是不是网络问题。找个网络通畅的时间段再试，往往就成功了。snap的下载服务器在国外，网络状态对安装成败影响非常大。如果长期网络环境受限，那就干脆放弃软件中心，老老实实用apt和手动下载的deb包，反而更稳。工具是为人服务的，别被它绑架了。