要查看指定 systemd 服务的完整配置树，需聚焦其运行时依赖层级结构而非静态文件；使用 systemctl list-dependencies --all --tree 查正向依赖，--reverse 查反向依赖，systemctl cat 查原始配置，systemctl verify 验证引用完整性，systemctl is-enabled/is-active 确认运行时状态。
要查看指定 systemd 服务的完整配置树，关键不是“配置文件内容”本身，而是它在启动逻辑中所处的依赖层级结构——即哪些单元必须先就位、谁拉起它、它又支撑谁。这个“树”是运行时依赖关系的可视化表达，不是静态文本树。
以下方法按用途分层说明，直接可用：
查看服务的正向依赖树（启动前必须激活的全部单元）
这是最常用的需求，反映“要启动 A，得先有 B、C、D……”。
运行
systemctl list-dependencies --all --tree 服务名
例如：systemctl list-dependencies --all --tree nginx.service
输出为缩进式树状结构，包含 Wants、Requires、After 等所有声明关系，并递归展开到最底层（如basic.target→sockets.target→system.slice等）。若树太深干扰判断，加
--depth=N限制层数：systemctl list-dependencies --all --tree --depth=2 nginx.service只关注强依赖和启动阻塞点（更贴近真实失败原因）：
systemctl list-dependencies --type=requires --type=after --tree 服务名
查看谁依赖该服务（反向依赖树）
用于评估停用/修改影响范围，比如关掉 sshd.service 会影响哪些上游单元。
- 运行
systemctl list-dependencies --reverse --all --tree 服务名
例如：systemctl list-dependencies --reverse --all --tree sshd.service
会显示所有显式声明Wants=或Requires=它的 service、target（如multi-user.target通过WantedBy=引用它），包括当前未启用的单元。
查看服务单元文件中的原始配置声明（源头依据）
依赖树来自配置，最终得回归 unit 文件验证。
-
执行
systemctl cat 服务名
例如：systemctl cat docker.service
重点看[Unit]段：-
Requires=：硬依赖，缺失或失败则本服务不启动 -
Wants=：软依赖，缺失不影响启动，但通常被拉起 -
After=：仅定义顺序，需配合 Wants/Requires 才构成实际依赖 -
BindsTo=：绑定依赖，被依赖单元停止时本服务自动停止
-
检查语法与引用完整性：
systemctl verify 服务名—— 报错会指出Requires=xxx.service not found或 target 不存在等问题。
验证依赖是否真正满足（运行时状态）
声明≠生效。需确认依赖单元不仅存在，还处于可用状态。
查每个依赖项的启用与活动状态：
systemctl is-enabled 依赖名和systemctl is-active 依赖名
例如发现network-online.target是enabled inactive(dead)，说明网络未就绪，可能拖慢或阻塞目标服务。快速定位启动卡点：
systemctl status 服务名中注意Loaded:行是否含not-found，Active:行是否提示failed due to dependency。
不复杂但容易忽略
