依赖未满足时应先用sudo dpkg -i安装失败后立即执行sudo apt --fix-broken install自动解决依赖，而非手动安装或强制跳过；卸载需分sudo dpkg -r和sudo dpkg -P两步，并手动处理systemd服务。
dpkg -i 安装失败：提示依赖未满足怎么办
直接用 dpkg -i 装 .deb 包，十有八九会卡在“依赖未安装”上，报错类似：dependency is not satisfiable: libxyz1 (>= 2.4)。这不是命令写错了，是 dpkg 本身不处理依赖——它只管把文件扔进系统，不管缺不缺库。
- 先运行
sudo dpkg -i package.deb，失败后别急着删包 - 立刻补一句
sudo apt --fix-broken install，apt 会扫描 dpkg 的中断状态，自动拉取并装好所有缺的依赖 - 如果 apt 报“无法定位软件包”，说明源里没这个依赖版本，得先确认源是否启用对应仓库（比如
universe或第三方源） - 不要手动下载依赖 deb 一个个 dpkg -i——容易套娃循环依赖，交给 apt 更稳
安装时想跳过依赖检查？能但不建议
用 --force-depends 可以硬装，比如 sudo dpkg -i --force-depends package.deb，但后果很实在：程序大概率启动就报 symbol lookup error 或直接 segfault。
- 仅限调试或临时验证文件结构，比如确认包里有没有某个配置路径
- 生产环境或日常使用，跳过依赖等于埋雷；即使当时能跑，升级相关库后可能突然崩
-
--force-all更危险，连架构不匹配（如 arm64 包装到 amd64）都拦不住，基本等于“我保证自己负责一切后果”
卸载 deb 包比安装还容易出错
很多人以为 dpkg -r 就完事，结果残留配置、服务没停、甚至 /etc 下的文件还留着，下次重装直接冲突。
- 查包名用
dpkg -l | grep keyword，别凭文件名猜——package.deb解压后实际包名可能是foo-bar - 干净卸载分两步：
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
想静默安装或脚本化？注意退出码和日志位置
dpkg -i 成功时返回 0，但只要有任何警告（比如 maintainer script 脚本执行失败），它也返回 0——这会让自动化脚本误判成功。
- 关键判断依据不是退出码，而是看输出里有没有
Errors were encountered while processing: - 日志默认记在
/var/log/dpkg.log，每行带时间戳和操作类型，排查回滚点比翻终端快得多 - 批量装多个 deb 时，别用
dpkg -i *.deb，顺序不可控；改用循环：for f in *.deb; do sudo dpkg -i "$f"; done，方便单个失败时中断或记录
