查包冲突需先用 apt-cache policy 查版本优先级，再用 dpkg -l 和 apt list 确认已安装版本；注意第三方源混入、手动 hold 包及文件所有权冲突，依赖分析用 apt-rdepends 和 aptitude why-not。
查哪个包在打架：apt-cache policy 和 dpkg -l 配合看
系统报 unmet dependencies 或安装时提示 “held broken packages”，大概率是两个包对同一个文件、库版本或配置路径提出了互斥要求。先别急着强制覆盖，用 apt-cache policy 看清楚当前源里各候选版本的优先级——比如你装了 libssl1.1，但新包要求 libssl3，apt-cache policy libssl1.1 libssl3 会立刻告诉你哪些源提供了哪个版本、谁被 pin 住了。
dpkg -l | grep ^i 能筛出已安装包，再配合 apt list --installed | grep xxx 确认具体版本号。注意：同一软件不同发行版打包名可能不同（如 python3-pip 在 Debian 是 python3-pip，Ubuntu 22.04 后改叫 python3-pip-whl），名字对不上就查不全。
- 别只信
apt install xxx的报错第一行，它常省略真正冲突链；要加-o Debug::pkgProblemResolver=yes让 apt 吐出完整依赖图 -
apt-mark showhold必查——有人手动apt-mark hold过关键包（如内核或 libc），会导致整个升级卡死 - 第三方源（如
deb [arch=amd64] https://repo.example.com stable main）一旦混入，apt-cache policy输出里会出现多个500优先级条目，这时得人工比对版本号，不能只看“最高优先级”
强制卸载前先看依赖树：apt-rdepends 和 aptitude why-not
想删掉某个包来腾地方？先搞清它是不是被其他重要服务暗中依赖。直接 apt remove xxx 可能顺手干掉 systemd 或 gnome-shell——不是夸张，是真实发生过。
apt-rdepends --reverse --no-recommends xxx 能列出所有反向依赖它的包（即“谁离不开它”）；而 aptitude why-not xxx 更狠，直接解释为什么当前系统状态不允许安装/升级 xxx，包括中间哪一层包锁死了版本。
-
apt-rdepends默认递归太深，加--depth 2控制输出长度，避免刷屏 -
aptitude不是所有系统默认装，Debian/Ubuntu 需先apt install aptitude；它比 apt 更擅长推导隐式冲突 - 如果
why-not返回 “Package xxx is not installed”，说明问题不在xxx自身，而在它依赖的某个子包——这时要把子包名填进去重试
降级或换源时绕不开的锁：/var/lib/dpkg/status 和 dpkg --force-confold
手动 dpkg -i 安装 deb 包失败，报 trying to overwrite '/path/to/file', which is also in package xxx，本质是 dpkg 发现两个包声称拥有同一个文件。这不是 apt 的锅，是 dpkg 层面的文件所有权冲突。
临时解法是 dpkg --force-overwrite -i xxx.deb，但风险高：可能覆盖掉系统关键配置。更稳妥的是先查清谁占了这个路径：dpkg -S /path/to/file。如果返回空，说明文件是手工放进去的，或来自未注册的包——这时删掉它再重装即可。
-
/var/lib/dpkg/status是 dpkg 的数据库，别直接编辑；真要修复，用dpkg --configure -a尝试续上中断的安装流程 -
dpkg --force-confold适用于配置文件冲突（比如 /etc/nginx/nginx.conf），它保留旧版，但要注意：新版功能可能因此失效 - 某些包（如
mysql-server）会在安装时生成随机 root 密码并写进日志，强制重装可能丢失该密码，得提前grep "temporary password" /var/log/mysqld.log
长期维护建议：用 apt-mark hold 锁关键包，但得定期 review
生产环境常把内核、数据库主版本、基础运行时（如 glibc）设为 hold，防止自动升级引发兼容问题。这没错，但 hold 是永久性的，不会随时间自动解除——三年前 hold 的 kernel-5.4，现在可能已无安全更新，却还在挡着 kernel-6.1 进来。
每月跑一次 apt-mark showhold | xargs apt-cache policy，检查被锁包是否还有可用更新；再用 apt list --upgradable 对照，确认没漏掉关键补丁。
- hold 包不会出现在
apt list --upgradable结果里，容易误以为“系统已最新” - 别对整套工具链（如
gcc-12+g++-12+cpp-12）分别 hold，用apt-mark hold gcc-12即可，dpkg 会连带锁住其依赖 - 某次
apt full-upgrade失败后，apt-mark showhold突然多出十几个包？可能是 apt 自动把冲突包临时 hold 了，得手动apt-mark unhold清理
软包冲突从来不是非黑即白的问题，而是版本、来源、安装方式、依赖策略四层叠加的结果。最麻烦的往往不是报错本身，是某个包十年前被手工编译安装过，没走 dpkg 注册，却占着 /usr/local/bin 下的关键路径——这种得靠 find /usr -name xxx 2>/dev/null 一层层翻。
