dpkg 不能自动解决依赖，必须用 apt 处理；安装失败时先 dpkg -i 再 apt --fix-broken install；卸载需 dpkg -r 后 dpkg -p；禁用 --force-depends 生产环境；脚本安装应用 for 循环而非通配符。
dpkg 不能自动解决依赖，硬装大概率失败；依赖问题必须交给 apt 处理，不是跳过就能绕过去。
dpkg -i 安装失败：提示 dependency is not satisfiable 怎么办
这不是命令写错了，是 dpkg 本身不拉依赖——它只解压、复制文件、运行 maintainer script，不管系统缺不缺 libxyz1 或版本对不对。
- 先执行
sudo dpkg -i package.deb，哪怕报错也别删包 - 立刻接一句
sudo apt --fix-broken install，apt 会读取 dpkg 的中断状态，自动补全所有缺失依赖 - 如果
apt --fix-broken install报 “无法定位软件包”，检查源是否启用了对应仓库（比如universe或第三方源），运行sudo apt update后再试 - 别手动下载一堆
.deb用dpkg -i逐个装——容易触发循环依赖，apt 才是唯一靠谱的协调者
想跳过依赖检查？--force-depends 能用但后果明确
加 --force-depends 确实能让 dpkg -i 过掉依赖校验，比如 sudo dpkg -i --force-depends package.deb，但它不解决实际缺失的符号或库。
- 程序启动时大概率报
symbol lookup error或直接segfault -
--force-all更危险：连架构不匹配（如在amd64系统上硬装arm64包）都拦不住 - 仅适合临时验证包结构，比如确认
/etc/default/下有没有某个配置模板；生产环境或日常使用等于主动放弃稳定性保障
卸载 deb 包：为什么 dpkg -r 后重装总冲突
因为 dpkg -r 只删二进制和主程序，不碰配置、服务、缓存，残留文件会干扰后续安装。
- 查真实包名别靠文件名猜：运行
dpkg -l | grep keyword或dpkg -I package.deb | grep Package - 干净卸载分两步：
sudo dpkg -r package-name→sudo dpkg -P package-name - 如果包注册了 systemd 服务，
dpkg -P不会自动 stop/disable，得手动补：sudo systemctl stop package.service && sudo systemctl disable package.service - 残留的
/etc/配置不会被清掉，除非你确认无用，否则别手删——有些服务重启后会按默认值重建，反而覆盖你改过的设置
脚本化安装多个 deb：别用 dpkg -i *.deb
dpkg -i *.deb 表面省事，实际顺序不可控，且单个失败时整个命令就停了，你根本不知道哪个包卡住、哪个没装。
- 用 for 循环更可控：
for f in *.deb; do sudo dpkg -i "$f"; done - 关键判断依据不是退出码（
dpkg即使警告也返回 0），而是终端输出里有没有Errors were encountered while processing: - 日志统一记在
/var/log/dpkg.log，带时间戳和操作类型，排查比翻终端快得多；脚本中可加grep "status installed" /var/log/dpkg.log | tail -n 1辅助验证
最常被忽略的点是：dpkg 没有“事务”概念，install 或 remove 中断后不会回滚，--configure 和 --unpack 是半成品状态，得靠 apt --fix-broken install 或手动 dpkg --configure -a 续上——但后者只修状态，不补依赖。
