linux systemd服务开机顺序由after与requires成对配置决定：仅after仅控时序，须加requires才构成硬性前提；弱依赖用wants，强绑定用bindsto，修改应覆盖至/etc/systemd/system/并执行daemon-reload。
Linux 中 systemd 服务的开机顺序不是靠“谁先写、谁排第几”决定的，而是通过单元文件里明确声明的依赖关系来控制。核心在于After和Requires配合使用，而不是单独设一个字段就完事。
依赖声明必须成对出现：After + Requires
只写 After=B.service 表示“我启动时间晚于 B”，但不保证 B 已成功运行；B 如果启动失败或卡住，你的服务仍会照常启动，大概率因连不上而崩溃。
加上 Requires=B.service 才构成硬性前提——B 必须成功启动，你的服务才被允许启动。
- 推荐写法：
After=B.service和Requires=B.service同时存在 - 若 B 是可选服务（比如日志轮转），改用
Wants=B.service，避免因 B 失败导致主服务无法启动 - 对强绑定场景（如 A 存在则 B 必须存活，B 挂了 A 也自动停），可用
BindsTo=B.service
修改位置和生效流程不能跳步
系统默认单元文件（如 /usr/lib/systemd/system/nginx.service）不建议直接改，应优先复制到 /etc/systemd/system/ 下再编辑——这是 systemd 推荐的覆盖方式。
- 备份原文件：
sudo cp /usr/lib/systemd/system/nginx.service /etc/systemd/system/nginx.service - 编辑该副本，在
[Unit]段添加依赖项 - 执行
sudo systemctl daemon-reload，否则所有改动都不生效 - 最后用
sudo systemctl enable nginx.service启用开机自启（仅创建软链接，不立即启动）
验证依赖是否真正起作用
别只看配置写了没，要确认实际加载逻辑是否符合预期：
- 查服务被哪些 target 拉起：
systemctl list-dependencies --reverse multi-user.target | grep nginx - 查 nginx 自身依赖链：
systemctl list-dependencies nginx.service - 看关键字段是否生效：
systemctl show nginx.service -p Wants,Requires,After - 检查是否已启用：
systemctl is-enabled nginx.service（输出enabled才算）
排查启动慢或失败的真实原因
服务启动失败，常常不是它自己有问题，而是前面某个依赖卡住了。比如设置了 After=network.target，但 network.target 又等 systemd-networkd-wait-online.service（默认超时 120 秒），整个链就被拖垮。
- 快速定位耗时大户：
systemd-analyze blame - 看最长依赖路径：
systemd-analyze critical-chain - 生成可视化启动图：
systemd-analyze plot > boot.svg，浏览器打开查看并行与阻塞点
