systemd启动以default.target为入口，通过target层级（如multi-user.target、sysinit.target）和依赖声明（Wants/Requires/After/BindsTo）控制服务拉起顺序与时机；依赖关系不等于执行顺序，After/Before才决定先后；实际依赖链可用list-dependencies、systemd-analyze等命令分析；default.target非终点，系统后续仍可动态激活服务。
Linux 使用 systemd 后，开机不再按传统脚本顺序执行，而是基于单元（unit）间的依赖关系并行启动服务。理解其启动顺序，关键在于理清 target 的层级结构和 WantedBy/Requires/After 等依赖声明的实际作用。
systemd 的启动入口是 default.target
系统启动时，systemd 默认加载 /etc/systemd/system/default.target（通常软链接到 multi-user.target 或 graphical.target）。这个 target 就是整个启动流程的“根节点”。它本身不干活，但通过 WantedBy= 反向定义了哪些 unit 应该被拉起。
- multi-user.target 表示基础命令行环境，依赖 basic.target → sysinit.target
- graphical.target 依赖 multi-user.target，并额外引入显示管理器（如 gdm、sddm）
- sysinit.target 负责早期系统初始化：挂载文件系统、启动 udev、初始化随机数、设置主机名等
依赖关系 ≠ 执行顺序，After/Before 才控制先后
仅写 Requires=network.service 表示“我启动前 network.service 必须已启动”，但不指定谁先谁后；若还需确保 network.service 完全就绪后再启动自己，必须加上 After=network.service。两者常成对出现：
- Wants=：弱依赖，目标 unit 启动失败不影响当前 unit
- Requires= + After=：强依赖且严格排序
- BindsTo=：比 Requires 更强，绑定生命周期（一挂全挂）
查看实际启动依赖链的方法
不用猜，用 systemd 自带命令直观分析：
- systemctl list-dependencies --reverse multi-user.target：看哪些服务被 multi-user.target 拉起
- systemctl list-dependencies --all sshd.service：展开 sshd 的全部正向依赖（含间接依赖）
- systemd-analyze plot > boot.svg：生成带时间轴的 SVG 启动流程图，直观看出并行与阻塞点
- systemd-analyze critical-chain：列出从启动开始到 default.target 的最长依赖路径，定位瓶颈
常见误区：default.target 不是“最后一步”
很多用户以为 default.target 是启动终点，其实它只是“初始目标”。systemd 会持续监听 unit 状态，后续手动启用的服务（如 docker）、定时器触发的任务（.timer）、或 socket 激活的服务（.socket），都可能在 default.target 达成后很久才启动。真正的“启动完成”没有绝对标志，systemctl is-system-running 返回 running 表示基本就绪，但不代表所有服务都已激活。
