dpkg -i 安装失败因不处理依赖，应先用 sudo dpkg -i 尝试，再运行 sudo apt-get install -f 自动修复；卸载用 -r 保留配置、-p 彻底清除；查包名用 dpkg -l | grep，查内容用 dpkg -c/-i，日常优先用 apt 而非绕过依赖硬装。
dpkg -i 安装失败：依赖未满足怎么办
直接 dpkg -i xxx.deb 失败，十有八九是报 dependency is not satisfiable 或一堆 unmet dependencies ——这不是命令错了，是 dpkg 本身不处理依赖，它只管“把包放进去”，不管“缺不缺库”。
- 先用
sudo dpkg -i xxx.deb尝试安装，失败后别删包，立刻执行sudo apt-get install -f -
-f（fix-broken）会扫描当前系统里所有半安装、依赖断裂的包，并自动拉取缺失依赖、补全配置 - 如果
apt-get install -f报找不到某个源里的包，说明你没启用对应软件源，得先确认/etc/apt/sources.list或/etc/apt/sources.list.d/下有对应条目 - 切忌手动下载一堆 .deb 来挨个
dpkg -i：顺序错、版本混，只会让依赖关系更乱
卸载 deb 包时：-r 和 -P 的区别必须分清
卸载不是删文件夹，dpkg 会记录状态。用错参数，下次重装可能出奇怪问题。
-
dpkg -r package-name只删程序文件，保留配置文件（比如/etc/nginx/下的设置）——适合想保留配置重装 -
dpkg -P package-name彻底清除，含配置、缓存、日志目录（如果包声明了这些）——适合彻底干净再装 - 不确定装的是哪个名？先查：
dpkg -l | grep keyword，注意输出第一列是实际包名，不是文件名（比如code_1.85.1-1699720249_amd64.deb对应包名通常是code） - 卸载后残留
/var/lib/dpkg/info/package-name.*文件？那是 dpkg 的状态记录，别手动删，否则dpkg -l会显示rc状态（removed config）
查看 deb 内容和安装路径：别盲装，先看清楚
尤其当 deb 来自第三方或内部构建，不确认内容就装，容易覆盖系统关键文件或写到奇怪路径。
- 看包里有哪些文件：
dpkg -c xxx.deb——输出类似drwxr-xr-x root/root 0 2026-02-10 14:22 ./usr/bin/mytool - 看它装完会往哪写：
dpkg -I xxx.deb查Installed-Size和Architecture，重点看Package名是否和预期一致 - 查已装包关联了哪些文件：
dpkg -L package-name，比如dpkg -L curl能看到所有被安装进系统的二进制、man、doc 路径 - 如果
dpkg -L报 “not installed”，说明该包根本没成功配置过，可能是dpkg --configure -a没跑完
dpkg 和 apt 不是替代关系，而是分工不同
很多人以为学会 dpkg -i 就不用 apt 了，其实它们像扳手和智能装配线：一个负责单点操作，一个负责整套协同。
-
dpkg是底层工具，专注 .deb 文件的解包、记录、触发 maintainer scripts（如 postinst） -
apt是上层包管理器，调用 dpkg，但额外做依赖解析、版本比对、仓库索引更新、安全校验（GPG）、自动清理等 - 日常装软件，优先走
sudo apt install xxx；只有离线、内网、测试包、或修复损坏状态时，才动dpkg - 误用
dpkg -i强装高版本 deb（比如 Ubuntu 24.04 的包装在 22.04 上），可能因 libc/glibc 版本不兼容直接崩溃，apt会拦住这种操作，dpkg不会
真正麻烦的从来不是命令敲错，而是绕过依赖检查硬上、卸载时留了一堆配置又忘了、或者把开发版 deb 当稳定版用——这些坑，dpkg 自己从不提醒，得靠人盯住。
