systemctl list-dependencies --all 服务名可递归展开所有层级依赖项，揭示完整依赖链；配合--depth、--type、--reverse等参数可精准分析正向/反向依赖、时序关系及状态验证。

如果您尝试分析某个 systemd 服务在启动过程中所依赖的其他单元，但仅执行基础命令无法获取完整关系链，则可能是由于默认输出未展开间接依赖或未区分依赖类型。以下是深入分析服务依赖关系的多种方法：

一、正向查看服务的全部依赖链

该方法用于确认目标服务启动前必须激活的单元集合，包括直接与间接依赖，覆盖 Wants、Requires、After 等声明关系。默认输出仅显示一级依赖，需加参数才能揭示完整结构。

1、执行 systemctl list-dependencies --all 服务名，例如 systemctl list-dependencies --all nginx.service，以递归展开所有层级的依赖项。

2、若依赖树过深导致信息冗余，可限制深度：运行 systemctl list-dependencies --all --depth=3 服务名，仅展示前三层依赖关系。

3、聚焦启动顺序逻辑，排除软依赖干扰：使用 systemctl list-dependencies --type=after 服务名，仅列出 After= 字段定义的时序依赖，更贴近实际启动阻塞点。

二、反向定位依赖该服务的其他单元

该方法用于评估停用或修改某服务可能影响的范围，识别哪些上游服务将其作为必要组件拉起，避免误操作引发级联故障。

1、运行 systemctl list-dependencies --reverse 服务名，例如 systemctl list-dependencies --reverse sshd.service，获取所有显式声明 Wants 或 Requires 该服务的单元。

2、为防止遗漏未启用单元，添加 --all 参数：执行 systemctl list-dependencies --reverse --all 服务名，确保输出包含已声明但当前未安装或未启用的依赖者。

3、检查 target 级反向依赖：若目标服务被某 target（如 multi-user.target）通过 WantedBy= 引用，该关系不会出现在正向输出中，必须依赖 --reverse 才能捕获。

三、解析服务单元文件中的原始依赖声明

该方法用于验证依赖是否被正确写入配置，识别拼写错误、缺失单元或不兼容的依赖类型，是排查 “not-found” 类错误的根本手段。

1、查看服务完整 unit 文件内容：执行 systemctl cat 服务名，定位 [Unit] 段落下的 Wants=、Requires=、After=、BindsTo= 等字段。

2、重点核对 Requires= 行是否引用真实存在的单元：若某行显示 Requires=redis-server.service，但系统中无此服务，则 systemctl verify 会报错且服务无法启动。

3、检查 After= 是否配合 Wants/Requires 使用：单独的 After= 不触发依赖服务启动，必须成对出现，例如 Wants=network-online.target 与 After=network-online.target 同时存在才有效。

四、以树状结构可视化依赖拓扑

该方法适用于复杂服务（如 docker、k3s），将嵌套依赖关系转化为缩进层级，便于快速识别关键路径与冗余分支。

1、生成带缩进的树形图：运行 systemctl list-dependencies --all --tree 服务名，例如 systemctl list-dependencies --all --tree docker.service。

2、识别状态标识符：输出中 ● 表示对应单元当前 active，○ 表示 inactive，→ 表示依赖方向；若某节点标为 not-found，说明其 unit 文件缺失或名称错误。

3、结合 --type 参数细化视图：添加 --type=require 可仅显示 Requires= 构成的强依赖树，排除 Wants= 的软依赖干扰。

五、验证依赖是否满足运行时条件

该方法用于确认声明的依赖不仅存在，而且已成功激活并处于可用状态，解决“配置正确但服务仍失败”的典型问题。

1、执行 systemctl verify 服务名，检查 unit 文件语法、引用的 target 是否存在、路径是否合法等基础完整性。

2、逐个检查被依赖服务的实际状态：对 list-dependencies 输出中的每个单元，运行 systemctl status 单元名，确认 Active 行为 active (running)，而非 inactive (dead) 或 failed。

3、查看被依赖服务的最近日志：针对状态异常的依赖项，执行 journalctl -u 单元名 -n 30 --no-pager，搜索 Failed to start、Connection refused、No such file 等关键错误线索。