要看 Linux 服务的依赖关系，核心是用 systemd 命令分析 Wants、Requires、After、BindsTo 等单元依赖声明：用 systemctl list-dependencies 正向 / 反向查依赖，加 –all 展开层级、–type=service 限定类型；systemctl show -p 查实际声明字段，systemctl cat 看完整 unit 文件；systemctl analyze plot 生成依赖图排查循环，critical-chain 定位启动瓶颈，journalctl 查失败原因；注意 target、.socket 激活和 drop-in 文件也影响依赖。
要看 Linux 服务的依赖关系，核心是用 systemd 自带的命令分析单元（unit）之间的 Wants、Requires、After、BindsTo 等依赖声明，而不是靠猜或翻 配置文件。
查服务直接依赖了哪些单元
运行以下命令，查看某个服务启动时明确要求加载或启动的其他单元：
-
systemctl list-dependencies --reverse servicename.service：反向查谁依赖它（比如查network.target被哪些服务需要） -
systemctl list-dependencies servicename.service：默认显示它正向依赖的单元（即它Wants或Requires的） - 加
--all可展开所有层级，加--type=service只看服务类型，避免混入 timer/mount 等
看依赖类型和语义 区别
仅知道“有依赖”不够，得明白 systemd 中不同依赖关键字的实际行为：
-
Requires=xxx：强依赖。如果 xxx 启动失败，本服务一定失败 -
Wants=xxx：弱依赖。xxx 启动失败不影响本服务继续启动 -
After=xxx/Before=xxx：只控制顺序，不表示必须存在或启动成功 -
BindsTo=xxx：比 Requires 更强——一旦 xxx 停止，本服务也会被自动停止
这些字段都在服务单元文件（/usr/lib/systemd/system/xxx.service 或 /etc/systemd/system/xxx.service）的 [Unit] 段里定义。
检查实际启动时的依赖解析结果
systemd 在启动时会构建依赖图，可以用下面方式验证真实行为：
-
systemctl show servicename.service -p Wants -p Requires -p After -p BindsTo：直接输出该服务声明的所有关键依赖字段值 -
systemctl cat servicename.service：查看完整 unit 文件，含注释和继承逻辑 - 启动后用
systemctl status servicename.service，注意“Loaded”行末尾括号里的“enabled; vendor preset: enabled”等提示，以及“Active”上方的“Since”和依赖链提示
排查依赖循环或启动卡住
如果服务启不动，很可能是依赖冲突或循环：
-
systemctl analyze plot > deps.svg：生成 SVG 依赖图（需安装 graphviz），用 浏览器 打开可直观看到环状结构 -
systemctl analyze critical-chain servicename.service：从目标服务倒推启动耗时最长的依赖链，定位瓶颈 -
journalctl -u servicename.service -n 50 --no-pager：看失败日志，常提示“Failed to start xxx.service: Unit xxx.service failed to load: No such file or directory.”——说明依赖的 unit 根本不存在
不复杂但容易忽略的是：依赖关系不仅来自服务自身配置，还可能来自 target（如 multi-user.target）、自动触发器（如 .socket 激活）、或 drop-in 覆盖文件（/etc/systemd/system/servicename.service.d/*.conf）。查全依赖，得把这几处都纳入视野。
