systemd服务启动顺序依赖需用After=与Wants=/Requires=组合：After=仅表时序，Wants=为弱依赖，Requires=为强依赖；避免循环依赖；验证须用systemd-analyze critical-chain等命令查真实链路，而非仅看配置。
systemd 服务启动顺序依赖怎么写
Linux 现在基本都用 systemd，控制启动顺序靠的是依赖关系，不是传统 SysV 的数字编号。写错依赖会导致服务起不来，或者起得太早——比如数据库还没监听，Web 服务就去连它，报 Connection refused。
关键不是“谁先谁后”，而是“谁等谁”。用 After= 和 Wants=（或 Requires=）组合才有效：
-
After=network.target只表示时间先后，不保证网络已就绪；真要等网卡配好，得加Wants=network-online.target+After=network-online.target -
Requires=redis.service表示强依赖：如果redis.service启动失败，本服务直接 abort，不会尝试启动 -
Wants=redis.service是弱依赖：redis.service启动失败不影响本服务继续，但本服务仍会在它之后启动（配合After=） - 避免循环依赖：
A Wants=B + After=B和B Wants=A + After=A会让systemd拒绝加载单元文件，报错Unit A has a dependency cycle with B
如何验证服务实际启动顺序
光看配置不顶用，得查真实执行流。最直接的方式是看启动时序图：
systemd-analyze plot > boot.svg
打开 boot.svg 就能看到所有服务横向排布、启动/结束时间轴。但更常用的是过滤关键服务：
-
systemd-analyze blame查耗时最长的服务（常暴露隐性阻塞） -
systemd-analyze critical-chain myapp.service显示从default.target到myapp.service的完整依赖链，每一步是否成功、耗时多少一目了然 -
journalctl -u myapp.service -u postgresql.service --since "1 hour ago"对比日志时间戳，确认 PostgreSQL 是否真在myapp.service启动前 ready
注意：systemd-analyze 默认只分析上次 boot，重启后数据刷新，别拿旧结果当依据。
