直接看 systemd-analyze time 就能知道总耗时和瓶颈在哪一阶段：它输出 kernel、initrd、userspace 三段连续耗时，分别对应内核初始化、initramfs 执行、systemd 加载所有 unit；userspace 占比超 80% 时需用 blame --all 进一步排查 activating 或 failed 的 .mount 单元。
直接看 systemd-analyze time 就能知道总耗时和瓶颈在哪一阶段，不用猜、不用装额外工具——所有 systemd 系统（Ubuntu 16.04+、CentOS 7+、Debian 9+ 等）都自带这个命令。
用 systemd-analyze time 快速定位三段耗时分布
它输出类似 Startup finished in 1.234s (kernel) + 3.456s (initrd) + 12.789s (userspace) = 16.479s，这三个值不是并列关系，而是启动链上的连续阶段：
-
kernel：从内核第一条指令执行到init进程（PID 1）创建完成；超 1s 就该查 BIOS Fast Boot 是否开启、NVMe 驱动是否内置、Secure Boot 是否引发额外验证 -
initrd：仅启用 initramfs 时存在，含 LVM 扫描、加密卷解锁等；高耗时常见于/etc/crypttab配置了交互式密码，或内核参数误加了rd.md=0导致 RAID 初始化跳过失败重试 -
userspace：systemd 加载所有 unit 的总耗时；占比超 80% 说明问题在服务层，下一步必须进blame，而不是调 BIOS
注意：systemd-analyze time 不包含 BIOS/UEFI 自检、GRUB 菜单停留、内核解压等前置时间，只反映 systemd 接管后的可测部分。
用 systemd-analyze blame --all 抓全慢单元
systemd-analyze blame 默认只列出状态为 active 的 .service 和 .mount 单元，但真正拖慢启动的，往往是卡在 activating (start) 或直接 failed 的 .mount 单元（比如 /etc/fstab 里写了已拔掉的 USB 盘、不可达的 NFS 地址）。
- 必须加
--all才能看到failed、activating、inactive等所有已加载 unit - 必须加
--no-pager防止终端截断长名字，尤其对 UUID 命名的设备（如dev-disk-by\x2duuid-xxx.mount） - 重点关注耗时 ≥ 500ms 的条目，特别是
NetworkManager-wait-online.service（常因 DHCP 超时卡住）、docker.service（镜像扫描阻塞）、以及各种.mount单元（检查/etc/fstab是否漏写nofail或x-systemd.timeout=5）
用 systemd-analyze critical-chain 看真实依赖瓶颈
systemd-analyze critical-chain 展示的是从启动起点到 default.target（或 graphical.target）的**最长依赖路径**，每一步都含实际耗时，比 blame 更能反映“为什么启动慢”。
- 例如它可能显示：
default.target → multi-user.target → sshd.service → network-online.target → NetworkManager-wait-online.service，而最后一步耗时 12s——这说明 SSH 启动被网络就绪卡住，而非sshd.service本身慢 - 如果链条末端是
NetworkManager-wait-online.service，但blame显示它只花了 0.2s，而链条里显示+6.7s，说明它前面的依赖（如network-pre.target）在等网络通，而实际网络压根没配好 - 若链条中出现
dev-disk-by\x2duuid-xxx.device或initrd-switch-root.service，说明瓶颈在内核初始化、initramfs 解压/挂载、或根文件系统识别阶段——这些阶段 systemd 尚未接管，blame统计无效
生成 SVG 时序图辅助判断并行与阻塞
systemd-analyze plot > boot.svg 导出的图表能直观看出哪些服务是串行等待、哪些是并行启动，还能发现隐性依赖导致的空档。
- 图中横向为时间轴，每条色块代表一个 unit 的启动过程；重叠表示并行，空隙反映等待依赖
- 需安装
graphviz（部分系统已预装）；若提示Failed to get dependency graph，可能是权限不足，尝试加sudo（但通常不需要） - 红色高亮常指向问题点，比如某个
.mount单元长时间独占启动线程，或某 service 在中间突然拉长整个链条
真正卡住启动的单元，往往藏在 blame --all 里，尤其是那些没显示耗时数字、只卡在 activating 状态的 .mount 单元——它们不会出现在默认 blame 输出中，却可能让整条 critical-chain 多等 30 秒。
