dpkg是debian系系统底层执行员，只负责安装文件和更新状态，不处理依赖；apt-get是高层调度员，自动解决依赖、查源、决策。离线装.deb或查包信息用dpkg；日常安装、升级、修复依赖必须用apt-get。
Debian系系统中，依赖问题不是“能不能装”，而是“怎么让系统自己理清楚”。核心在于理解 apt-get 是调度员，dpkg 是执行员——调度员管依赖、查源、做决策；执行员只管把文件放进指定位置、改写状态，不管前后是否通顺。
什么时候该用 dpkg，什么时候必须交给 apt-get
dpkg 适合这些场景：
- 你已下载好 .deb 文件，且确认所有依赖都已就绪（比如离线环境部署）
- 需要精确查看某个包装了哪些文件：dpkg -L nginx
- 排查某个二进制或配置文件来自哪个包：dpkg -S /usr/bin/apt
- 强制重装一个已损坏但 apt 认为“正常”的包：sudo dpkg -i --force-overwrite package.deb（慎用）
apt-get 才是日常主力：
- 安装新软件、升级系统、清理冗余包——它会自动拉取依赖、解决版本冲突、跳过已满足项
- 修复中断安装：sudo apt --fix-broken install 比反复 dpkg --configure 更可靠
- 批量操作更安全：apt 能识别“被其他包依赖”的库，不会误删；dpkg -P 则可能直接干掉共享依赖
依赖报错时的四步定位法
看到 “unmet dependencies” 或 “half-configured”，别急着重装。先快速锁定源头：
- 运行 dpkg -l | grep '^iU' —— 找出“已解包未配置”的包（U 表示 unpacked）
- 运行 dpkg --get-selections | grep deinstall —— 查看半卸载残留（deinstall 状态需 purge）
- 检查错误提示里明确指出的缺失包名，例如 Depends: libssl3 but it is not installable，再用 apt-cache policy libssl3 看该包是否在源中、版本是否匹配
- 翻日志：tail -n 20 /var/log/dpkg.log，确认最后失败的是哪个包、卡在哪一步
修复依赖断裂的实用组合拳
多数依赖异常可通过以下顺序恢复，无需重装系统：
- sudo dpkg --configure -a：完成所有挂起的配置动作，解决因断电/强制退出导致的 iU 状态
- sudo apt clean && sudo apt update：清除旧缓存，刷新软件源索引，避免元数据错位干扰判断
- sudo apt --fix-broken install：让 apt 自动计算缺失依赖并补全，这是最常用也最稳妥的一环
- 若仍失败，根据错误提示手动安装关键依赖，例如：sudo apt install libglib2.0-0=2.74.6-2（指定版本防冲突），再重试 fix-broken
预防比修复更重要
几个简单习惯能大幅降低依赖混乱概率：
- 不混用 dpkg -i 和 apt install 同一软件（比如先 dpkg 装了 nginx，再 apt install nginx 会导致状态冲突）
- 升级前先执行 sudo apt update，避免因源未同步导致版本不兼容
- 卸载软件优先用 sudo apt remove --purge，而不是 dpkg -P，前者会自动处理反向依赖
- 定期清理无用包：sudo apt autoremove --purge，尤其在移除大型桌面环境后
