dpkg -i 安装失败主因是其不处理依赖，仅解包执行脚本；缺依赖时应先用 sudo dpkg -i 尝试安装，再立即运行 sudo apt --fix-broken install 自动补全依赖，离线环境需提前下载全部依赖包并配置本地源后使用 apt install ./package.deb。
dpkg -i 为什么装不上，缺依赖到底该怎么补
直接 sudo dpkg -i package.deb 失败，几乎全是依赖问题。这不是命令写错了，是 dpkg 本身不查依赖、不拉包、不判断版本兼容性——它只负责把文件解压到指定路径并执行脚本。报错类似 dependency is not satisfiable: libcurl4 (>= 7.68.0)，说明系统里要么没装 libcurl4，要么版本太低。
离线环境下，sudo apt --fix-broken install 或 sudo apt-get install -f 会立即失败，因为源不可达。这时候不能靠它“自动修复”，得提前把所有依赖包一并准备好。
- 先用
dpkg -I package.deb查Depends:字段，确认它要哪些包和最低版本 - 再用
apt download（在有网机器上）批量拉取目标包 + 所有递归依赖：apt download $(apt-rdepends package-name | grep -v "^ " | xargs) - 把下载好的所有
.deb文件拷到离线机，统一用dpkg -i *.deb或循环安装（推荐后者，便于定位失败点）
用 apt install ./package.deb 在离线环境是否可行
可以，但前提是你已把整个依赖树的 .deb 文件都放在本地，并且配置了本地 APT 源。否则 sudo apt install ./package.deb 仍会尝试联网找依赖，报 E: Unable to locate package 或 E: Failed to fetch。
它的优势在于能自动排序安装顺序、跳过已存在包、处理冲突，比裸用 dpkg -i 更健壮。但离线时必须配合本地仓库：
- 把所有
.deb放进一个目录，比如/var/local/debs - 运行
dpkg-scanpackages . /dev/null | gzip > Packages.gz生成索引 - 在
/etc/apt/sources.list.d/offline.list加一行：deb [trusted=yes] file:/var/local/debs ./ - 然后
sudo apt update && sudo apt install ./package.deb才真正离线可用
强制跳过依赖（--force-depends）的风险在哪
加 --force-depends 能让 dpkg -i 硬装成功，但后续大概率出 runtime 错误，比如：symbol lookup error: undefined symbol: curl_easy_setopt，或直接 segmentation fault。
这是因为缺失的库不仅影响安装，更决定程序能否加载和调用关键函数。硬装后看似“装上了”，实际只是把二进制扔进了 /usr/bin，运行时找不到符号就崩。
- 仅适合临时验证包结构（如确认
postinst脚本是否可执行） -
--force-all更危险：连架构不匹配（arm64包装到amd64）都不拦，等于放弃所有安全检查 - 生产环境或需要长期运行的服务，跳过依赖 = 埋一个等升级或重启才触发的雷
卸载残留和服务怎么清理干净
很多人只跑 sudo dpkg -r package-name，结果 /etc 下配置还在、systemd 服务没停、下次重装直接冲突。根本原因是 dpkg -r 只删程序文件，不碰配置和状态。
真正干净卸载分三步走：
- 先查真实包名：
dpkg -l | grep keyword，别凭.deb文件名猜（code_1.85.1-1699720249_amd64.deb对应包名通常是code） - 停并禁用服务：
sudo systemctl stop package-name.service && sudo systemctl disable package-name.service - 再执行：
sudo dpkg -P package-name（-P才删配置、缓存、/var/lib/dpkg/info/下的状态记录）
如果已经乱了，dpkg -l 里看到状态是 rc（removed config），说明配置残留但程序已删，此时手动删 /etc/package-name/ 和 /var/lib/dpkg/info/package-name.* 是最后手段，但风险高——可能误删其他包共用的配置。
