应先触发报错获取缺失项，再用apt-cache policy或dnf provides等命令精准定位未满足依赖，结合ldd、dpkg -l | awk '/^iU$/'、systemctl list-dependencies等工具分场景排查安装、运行、服务三类依赖问题。

直接查未满足的依赖，关键不是“列出来所有依赖”，而是定位哪些依赖当前缺失或冲突——系统本身不维护一个静态的“未满足清单”，而是在安装、启动或运行时动态暴露问题。核心思路是：先触发报错，再用命令精准解析错误源头。

看包管理器报错时的缺失项

当 apt install 或 yum install 失败，错误里明确写了 Depends: xxx but it is not installable 或 failed dependencies: libxxx.so.1，这就是最真实的未满足依赖。别跳过这行，它是第一手线索：

• 对 apt 系统：运行 apt-cache policy xxx，确认该包是否在启用的源中存在、版本是否匹配
• 对 rpm 系统：用 dnf provides "libxxx.so.1" 或 rpm -qf /usr/lib64/libxxx.so.1 2>/dev/null || echo "not found" 查它该由哪个包提供，再确认该包是否已安装
• 检查 /etc/apt/sources.list 和 /etc/yum.repos.d/，混用不同发行版或版本的仓库是常见原因

查已安装程序实际缺哪些动态库

程序能装上但运行时报 error while loading shared libraries: libxxx.so.1: cannot open shared object file，说明运行时依赖未就位。这时用：

linux-sysadmin

Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...

下载

• ldd ./your_program | grep "not found" —— 快速标出缺失的 .so 名
• readelf -d ./your_program | grep NEEDED —— 更安全，只读文件不加载，列出所有声明依赖（不含路径）
• ldconfig -p | grep libxxx —— 查系统缓存里有没有这个库；若无，再搜文件：find /usr -name "libxxx.so.*" 2>/dev/null

找卡住没配置的已下载包（apt 特有）

apt 报 “unmet dependencies” 很多时候不是真缺包，而是某个已下载但没完成配置的包阻塞了整个链。这类包状态是 iU（installed, unpacked, unconfigured）：

• 运行 dpkg -l | awk '$1 ~ /^iU$/ {print $2}' 列出全部未配置包
• 对每个包执行 sudo dpkg --configure <pkgname> 或 sudo apt --fix-broken install（后者本质就是批量配置这些 iU 包）
• 注意：如果某个 iU 包本身依赖新版库，而系统只有旧版，apt --fix-broken 可能强行降级——此时应先手动解决那个包的依赖

查服务启动失败背后的依赖断点

systemd 服务报 Failed to start xxx.service: Dependency failed，说明其 unit 文件中声明的 Requires/Wants 服务没起来：

• 运行 systemctl status xxx.service，看 Loaded 行是否提示 not-found 或 masked，Active 行是否显示 dependency failed
• 用 systemctl list-dependencies --reverse xxx.service 看谁拉起了它；用 systemctl list-dependencies xxx.service 看它依赖谁
• 对报错中提到的依赖服务，逐个检查：systemctl is-active <dep.service> 和 systemctl status <dep.service>