在 Ubuntu 中安装 .deb 后缀安装包，最省事也最稳妥的方法通常是使用 apt install ./xxx.deb。Ubuntu 16.04 及更高版本已原生支持这种安装方式，能够自动解析依赖并安装缺失组件，整体成功率更高；操作时需要进入 .deb 文件所在目录执行命令，而且 ./ 这一写法不能省略，安装前建议先执行 sudo apt update。
使用 apt install ./xxx.deb 安装 .deb 包最简单省心
对于 Ubuntu 16.04 及以上版本，系统自带的 apt 工具已经支持直接安装本地 .deb 文件，并且会自动分析依赖关系、从软件源获取所需缺失包并完成安装。这种 Ubuntu 安装 deb 包的方法兼顾效率与稳定性，适合大多数普通用户和服务器环境。
实际操作时要注意以下几点：
- 必须在 .deb 安装包所在目录下执行命令，且命令中的
./不能省略，否则apt可能会把它识别成软件源中的同名软件包 - 正式安装前建议先运行
sudo apt update，避免因为软件源索引过旧而导致依赖解析失败 - 终端一般会提示“下列【新】软件包将被安装”，确认内容无误后输入
Y并回车即可继续 - 如果出现“无法定位软件包”的报错，通常需要检查 .deb 包架构是否与当前系统一致，例如 arm64 系统无法直接安装 amd64 的 deb 安装包
遇到 dpkg: dependency problems 时，不建议直接硬装 dpkg -i
dpkg -i 属于更底层的 Debian/Ubuntu 安装命令，它的主要作用是解包和注册软件包，本身并不会自动处理依赖。因此，直接使用它安装依赖未满足的 .deb 文件时，很容易报错，最常见的提示之一就是：dpkg: dependency problems prevent configuration of xxx。
如果你已经执行过 dpkg -i 并安装失败，推荐按以下方式修复：
- 立即执行
sudo apt --fix-broken install，用于修复缺失依赖和未完成配置的软件包 - 该命令会自动扫描当前系统中状态异常的包，并尝试下载相关依赖后完成安装配置
- 修复完成后通常不需要再次手动运行
dpkg -i，因为apt --fix-broken install往往已经把原来的 deb 包处理完成 - 如果仍然失败，通常说明当前软件源中没有对应依赖包，这时可以考虑改用
gdebi，或者进一步检查该 .deb 包是否适用于当前 Ubuntu 版本
Ubuntu 图形界面双击安装 .deb 失败，常见原因是依赖或权限问题
很多用户习惯通过 Ubuntu 软件中心或 Software Install 双击安装 deb 文件，看起来操作简单，但其底层依赖的其实是 gdbus 与 packagekit 相关机制，因此对依赖关系、桌面服务状态以及 dbus 权限都比较敏感。常见表现包括：点击“安装”后按钮变灰却没有后续反应、进度条长期卡住，或者直接弹出“准备失败”等提示。
出现这类问题时，可以通过以下方式快速排查和绕过：
- 先在终端执行
pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY gdebi-gtk，测试是否能够正常唤起 gdebi 图形安装界面；如果可以，通常说明 dbus 权限没有明显异常 - 如果所有图形安装工具都无法使用，建议直接切换到终端，使用
sudo apt install ./xxx.deb安装，这种方法不依赖桌面环境，在 Ubuntu Server 或远程环境中同样适用 - 部分企业定制版 Ubuntu 可能默认禁用了
packagekit，此时双击安装没有任何响应属于正常现象，并不一定是操作错误
gdebi 更适合查看依赖详情或进行离线安装部署
gdebi 是一个轻量级的 GUI/CLI 安装工具，它的优势不在于“比 apt 更强”，而在于“比 apt 更直观”。在安装本地 .deb 包之前，gdebi 会明确列出所有将要安装的依赖项，方便用户提前判断软件来源、依赖内容以及是否需要预先准备相关文件。
使用 gdebi 时，需要了解以下前提和限制：
- 需要提前安装：命令行版本可执行
sudo apt install gdebi-core，图形版本可安装gdebi - CLI 模式下可使用
sudo gdebi ./xxx.deb，程序会暂停并等待你确认依赖列表后再继续安装 - 它不会自动刷新软件源信息；如果依赖包不在当前缓存或本地环境中，仍然会回退到 apt 获取，因此离线安装前最好提前通过
apt download准备好相关依赖包 - 在 Ubuntu Server、无桌面系统或远程 SSH 会话中，命令行版
gdebi往往比图形安装工具更稳定可靠
需要注意的是，Ubuntu 安装 deb 包时的依赖解析并不是“万能自动修复”，它完全受当前 apt 软件源可用性的影响。同一个 .deb 文件可能在 Ubuntu 22.04 中可以正常安装，但在 Ubuntu 24.04 中失败，这往往只是因为某个依赖库已经被移除、替换或更名。遇到这种情况，更有效的做法是使用 apt-cache policy 检查具体依赖包状态，而不是反复尝试不同的安装命令。
