APT 软件包管理实战：软件源、版本检查与故障修复

上一篇解决“怎么装软件”，本篇进一步解决运维中常见的三个问题：软件从哪里来、系统实际会安装哪个版本，以及安装失败后怎样安全恢复。APT 是给管理员交互使用的前端工具；底层的 dpkg 维护已安装 deb 包数据库；写无人值守脚本时通常使用界面更稳定的 apt-get。

一、软件源文件在哪里

APT 会从软件源（Software source）下载索引和软件包。Ubuntu 24.04 LTS 及以后默认使用 deb822 格式，官方源通常位于：

/etc/apt/sources.list.d/ubuntu.sources

较早版本常使用 /etc/apt/sources.list。先判断系统版本，再查看文件，不要直接照抄其他版本的源：

cat /etc/os-release
ls -l /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

修改软件源前先备份原文件。更换镜像后执行 sudo apt update，确认没有签名（Signature）、发行版代号（Codename）或超时错误。为了所谓“速度”混用不同 Ubuntu 版本的软件源，很容易造成依赖损坏。

二、确认包状态和候选版本

apt policy nginx
dpkg -l nginx
dpkg-query -W -f='${Status} ${Version}\n' nginx

apt policy 的 Installed 是已安装版本，Candidate 是下一次安装或升级会选择的候选版本。dpkg -l 开头的 ii 通常表示已经正常安装。如果只知道命令名，不知道软件包名，可先用 command -v nginx 找到文件，再用 dpkg -S /usr/sbin/nginx 反查所属包。

查看某次操作计划但暂不执行，可使用模拟（Simulation）：

apt -s install nginx
apt -s remove nginx

模拟输出不会修改系统，非常适合在正式服务器上预判会新增、升级或删除哪些依赖。

三、锁定和解除版本

某些业务要求暂时不升级特定软件包，可以使用保留（Hold）：

sudo apt-mark hold nginx
apt-mark showhold
sudo apt-mark unhold nginx

Hold 只适合短期维护，不应成为永久逃避安全更新的办法。记录锁定原因和解除日期，否则几个月后很容易忘记，留下已知漏洞。

指定版本安装前先查看可用版本：

apt list -a nginx
sudo apt install nginx=版本号

降级可能与配置文件或依赖版本不兼容，生产环境应先在测试机验证。

四、安装中断或依赖损坏怎么办

先读清楚屏幕上的第一条实际错误，不要连续复制十几个“修复命令”。常用的温和处理顺序是：

sudo dpkg --configure -a
sudo apt --fix-broken install
sudo apt update
sudo apt upgrade

dpkg --configure -a 完成已解包但尚未配置的软件；--fix-broken install 尝试修复依赖。若提示锁文件（Lock file）被占用，先用 ps 或 systemctl status unattended-upgrades 判断是否有正常更新正在运行。不要直接删除 /var/lib/dpkg/lock*，否则可能破坏正在进行的包操作。

软件文件被误改时，可尝试重新安装：

sudo apt install --reinstall 软件包名

但 /etc 下由管理员维护的配置文件（Configuration file）通常会被保留。重装不等于恢复业务配置，重要配置必须有自己的备份和版本记录。

五、apt 和 apt-get 的使用边界

人在终端交互时，apt 输出友好并显示进度。定时脚本（Script）则建议使用 apt-get，并明确处理返回值：

sudo apt-get update && sudo apt-get upgrade

不要把自动升级脚本简单写成每天强制 -y 后不看结果。服务器更稳妥的做法是安装安全更新策略、保留日志、设置失败告警，并把可能重启服务或内核的升级安排在维护窗口（Maintenance window）。

六、更新后的验证清单

systemctl --failed
journalctl -p err -b --no-pager | tail -n 50
df -h
test -f /var/run/reboot-required && cat /var/run/reboot-required

依次检查失败服务、本次开机的错误日志、磁盘空间和是否需要重启。Web、数据库、SSH 等关键服务还应分别做一次连接测试。虚拟机快照只能帮助快速回退，不应替代应用数据和配置文件备份。

最后记住一个原则：先 update 更新索引，查看计划，再 upgrade；遇到错误先理解原因，避免用删除锁文件、强制覆盖或混用软件源的方法“硬修”。

七、架构、依赖与虚拟包

服务器常见架构是 amd64，树莓派和部分云主机可能是 arm64。先用以下命令确认：

dpkg --print-architecture
uname -m

官网下载 deb 时若选错架构，APT 无法正常安装。软件包的 Depends 表示必须依赖，Recommends 表示通常建议一起安装，Suggests 则是可选功能。查看依赖可用：

apt show 软件包名
apt-cache depends 软件包名
apt-cache rdepends 软件包名

最后一条是反向依赖（Reverse dependencies），用于判断还有哪些包依赖它。某些名称属于虚拟包（Virtual package），本身不包含具体文件，而是由多个实际软件包之一提供。看到“没有安装候选”时先读完整提示，不要随便添加陌生软件源。

八、配置文件升级提示怎么选

升级服务软件时，如果本地配置被修改，系统可能询问保留当前本地版本（Keep the local version currently installed）还是安装维护者版本（Install the package maintainer's version）。生产环境通常先保留现有配置，待升级完成后比较差异：

find /etc -type f \( -name '*.dpkg-dist' -o -name '*.dpkg-old' \) 2>/dev/null

.dpkg-dist 往往是新维护者版本，.dpkg-old 可能是被替换的旧文件。不要不看内容就删除，用 diff -u 旧文件 新文件 对比，再把需要的新选项合并到当前配置。完成后运行服务自己的语法检查并重新加载。

九、从日志还原一次 APT 操作

less /var/log/apt/history.log
less /var/log/apt/term.log

history.log 记录安装、升级、删除及调用命令，term.log 保存更详细的终端输出。若故障刚好发生在一次升级后，先找到对应时间段和被改动的软件包，再查看服务日志，不必凭感觉重装整个系统。

自动清理前同样应保留计划：

apt -s autoremove

确认没有业务需要的内核、驱动或依赖后才执行真正的 sudo apt autoremove。对于远程服务器，涉及内核、网络和 SSH 的变更尤其要安排控制台或带外管理作为退路。

如果 APT 报磁盘空间不足，先检查 /var、/boot 和根分区，不要随手删除 /var/lib/dpkg。旧内核通常应交给 apt autoremove 管理；下载缓存可用 apt clean 清理。空间恢复后再运行 sudo dpkg --configure -a，让被中断的软件包完成配置，并检查关键服务是否恢复。

本文为中文学习整理并加入运维检查流程。资料来源：Ubuntu Server 官方文档：Install and manage packages。