systemctl list-dependencies 可查看服务依赖树，支持正向（默认）、反向（--reverse）、深度（--depth）、类型（--type）等分析；配合 systemctl cat 和 systemd-analyze critical-chain 能精准定位启动瓶颈。
直接用 systemctl list-dependencies 就能看清服务的启动依赖树，配合几个关键参数就能覆盖正向、反向、深度和类型等不同分析需求。
正向查清一个服务要拉起哪些单元
运行 systemctl list-dependencies 服务名 可看到它直接依赖的服务和 target。默认只显示一级，想看完整链路必须加 --all：
-
systemctl list-dependencies --all nginx.service：递归展开所有层级，包括 Wants、Requires、After 关系 -
systemctl list-dependencies --all --depth=2 nginx.service：限制只显示两层，避免信息过载 -
systemctl list-dependencies --type=after nginx.service：聚焦启动时序，只看 After= 定义的“必须在之后”关系，更贴近实际阻塞点
反向查谁依赖这个服务
停掉一个服务前，得知道会影响哪些上层服务。用 --reverse 找出所有显式声明了 Wants 或 Requires 它的单元：
-
systemctl list-dependencies --reverse sshd.service：列出当前启用并依赖 sshd 的服务 -
systemctl list-dependencies --reverse --all sshd.service：加上--all后还能看到已声明但未启用、甚至未安装的依赖者，比如某 .service 文件里写了Wants=sshd.service却没启用该服务 - 特别注意 target 级依赖：如果某个 service 通过
WantedBy=multi-user.target被拉起，这种关系只有--reverse能捕获，正向命令看不到
结合 unit 文件确认原始声明
依赖树是运行时推导的，但根源在配置文件里。用 systemctl cat 查看真实定义：
-
systemctl cat docker.service：输出完整 unit 内容，重点看[Unit]段中的Requires=、Wants=、After=、BindsTo= -
Requires=redis-server.service若系统中没有 redis-server.service，服务就无法启动，systemctl verify docker.service会报错 - 单独写
After=network.target不触发启动，必须搭配Wants=或Requires=才有效
用 critical-chain 定位启动瓶颈
依赖树告诉你“要等谁”，systemd-analyze critical-chain 告诉你“真正卡在哪”：
-
systemd-analyze critical-chain：从default.target往回追溯最长串行链，每行带@X.XXXs（启动时间点）和+Y.YYYs（自身耗时） - 瓶颈不在
+最大的那个服务，而在相邻两行@时间差最大的地方——比如network-online.target @6.501s和下级NetworkManager-wait-online.service @2.199s相差 4.3 秒，说明网络就绪严重拖慢整条链 -
systemd-analyze critical-chain docker.service：指定服务查它的上游瓶颈，跳过无关分支
