systemctl list-dependencies是查看systemd服务依赖关系树的最直接有效工具；加--tree显示缩进树状结构，--all展开所有依赖类型，--reverse查反向依赖，结合systemctl cat和systemd-analyze可验证配置并分析启动性能。

直接用 systemctl list-dependencies 命令就能查看服务的依赖关系树结构，它是 systemd 自带的、最常用也最有效的工具，不需要额外安装。

用 --tree 显示清晰的缩进树状图

默认输出是扁平列表，加 --tree 参数后会以缩进层级呈现父子依赖关系，一眼看出启动顺序和嵌套结构：

• systemctl list-dependencies --tree nginx.service —— 查看 nginx 的完整依赖树
• systemctl list-dependencies --tree --all sshd.service —— 加 --all 展开所有类型依赖（包括 Wants、After 等）
• systemctl list-dependencies --tree --type=requires nginx.service —— 只显示强依赖（Requires=），排除弱依赖干扰

用 --reverse 找出谁依赖这个服务

停用或修改某个服务前，必须知道哪些上层服务靠它支撑。--reverse 能翻转依赖方向：

travel-memory-preservation-system

系统化保存旅行记忆的方法

下载

• systemctl list-dependencies --reverse --all docker.service —— 列出所有显式声明依赖 docker 的单元，包括未启用的
• systemctl list-dependencies --reverse multi-user.target —— 查看哪些服务通过 WantedBy=multi-user.target 被拉起（这类关系正向查不到）

结合 systemctl cat 验证原始配置

树状图反映的是声明逻辑，最终是否生效要看 unit 文件怎么写的。直接读源配置可确认依赖是否真实存在：

• systemctl cat nginx.service —— 查看 [Unit] 段中 Wants=、Requires=、After= 等字段
• 重点检查 Requires= 后的服务名是否存在：systemctl list-unit-files | grep "redis"
• 若某行写 Requires=redis-server.service，但系统里实际叫 redis.service，就会启动失败

用 systemd-analyze 辅助分析启动链

当服务启动慢或失败时，依赖树只是起点，还需看实际耗时和关键路径：

• systemd-analyze blame —— 按启动耗时倒序列出所有单元，快速定位拖慢启动的服务
• systemd-analyze critical-chain nginx.service —— 显示从启动开始到该服务就绪的最长依赖链，含每个环节耗时
• systemd-analyze verify nginx.service —— 检查 unit 文件语法及基础依赖完整性（如引用的 target 是否存在）