systemd-analyze time 直接显示 kernel/initrd/userspace 三阶段耗时，精准定位启动瓶颈；需配合 blame --all 和 critical-chain 分析真实慢服务与依赖路径，并用 plot 生成时序图验证并行关系。
直接运行 systemd-analyze time 就能知道总耗时和瓶颈在哪一阶段，不用猜、不用装额外工具——所有 systemd 系统（Ubuntu 16.04+、CentOS 7+、Debian 9+）都自带这个命令。
看三阶段耗时分布：kernel / initrd / userspace
运行 systemd-analyze time 输出类似：
Startup finished in 1.234s (kernel) + 3.456s (initrd) + 12.789s (userspace) = 16.479s
这三个值是连续阶段，不是并列关系：
-
kernel：从内核第一条指令执行到systemd进程（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 --no-pager --all
systemd-analyze blame 默认只列出状态为 active 的 service 和 mount 单元，但真正拖慢启动的，往往是卡在 activating (start) 或直接 failed 的 .mount 单元（比如 /etc/fstab 里写了已拔掉的 USB 盘、不可达的 NFS 地址）。
- 必须加
--all才能看到所有已加载 unit（含failed、activating、inactive） - 必须加
--no-pager，否则终端宽度截断长名，例如dev-disk-by\x2duuid-1234567890abcdef.mount显示不全 - 重点关注耗时 ≥ 500ms 的条目，特别是：
NetworkManager-wait-online.service（常因 DHCP 超时卡住）、docker.service（镜像扫描阻塞）、各种.mount单元（检查是否漏写nofail或x-systemd.timeout=5）
看真实依赖瓶颈：用 systemd-analyze critical-chain
systemd-analyze critical-chain 展示的是从启动起点到 default.target 的最长依赖路径，每一步的时间是“该 unit 自身启动耗时”，不包含上游等待时间。容易误解成“它慢所以要优化它”，其实它可能自己很快，只是上游卡住了。
- 如果链条末端是
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统计无效 - 此时应切换诊断路径：检查
initramfs大小（ls -lh /boot/initramfs-$(uname -r).img，超 50MB 容易拖慢解压）、确认磁盘 UUID 是否稳定（blkid和/etc/fstab是否一致）、查看内核日志起点（dmesg -t | head -20）
生成可视化时序图：用 systemd-analyze plot
systemd-analyze plot > boot.svg 可导出 SVG 格式的启动时序图，直观展示服务依赖与并行/串行关系：
- 图中横向为时间轴，每条色块代表一个 unit 的启动过程；重叠表示并行启动，空隙反映等待依赖
- 需要安装
graphviz（部分系统已预装）；若提示 “Failed to get dependency graph”，可能是权限不足，尝试加sudo（但通常不需要） - 对排在
blame前 5 的服务，用此图观察它们是否真正串行，还是被其他 unit 拖累
真正卡住启动的单元，往往藏在 blame --all 里，尤其是卡在 activating 状态的 .mount 单元——它们不会出现在默认 blame 结果中，却会把整个关键路径拖长数秒甚至十几秒。
