systemd-analyze time 显示启动三阶段耗时，kernel/initrd/userspace 串行叠加；blame --all --no-pager 定位慢单元；critical-chain 揭示真实依赖瓶颈；plot 可视化验证并行与阻塞。
直接看三阶段耗时分布，用 systemd-analyze time
先敲这行命令，5 秒内就能知道瓶颈大概在哪： systemd-analyze time。输出类似 Startup finished in 718ms (kernel) + 1.713s (initrd) + 17.079s (userspace) = 19.511s，这三个值是串行关系，不是并列：
-
kernel阶段超 1s，重点查 BIOS Fast Boot 是否关闭、NVMe 驱动是否内置、Secure Boot 是否引发额外验证 -
initrd阶段只在启用 initramfs 时存在；高耗时常见于/etc/crypttab配了交互式密码，或内核参数误加了rd.md=0导致 RAID 初始化失败重试 -
userspace占比超 80%，说明问题在服务层，下一步必须进blame，而不是调 BIOS 或换固件
注意：systemd-analyze time 不含 BIOS/UEFI 自检、GRUB 菜单停留、内核解压等前置时间，只反映 systemd 接管后的可测部分。
找真正拖慢启动的单元，用 systemd-analyze blame --no-pager --all
systemd-analyze blame 默认只列 active 状态的服务，但卡住开机的往往藏在 activating 或 failed 的 .mount 单元里——比如 /etc/fstab 里写了已拔掉的 USB 盘、不可达的 NFS 地址，或者 UUID 错误的磁盘。
- 必须加
--all：强制列出所有已加载 unit（含failed、activating） - 必须加
--no-pager：防止终端截断长名，例如dev-disk-by\x2duuid-1234567890abcdef.mount显示不全 - 重点关注耗时 ≥ 500ms 的条目，尤其是：
NetworkManager-wait-online.service（常因 DHCP 超时卡住）、docker.service（镜像扫描阻塞）、各类.mount单元（检查是否漏写nofail或x-systemd.timeout=5）
注意：blame 统计的是 unit 从 start 到 running 的 active 时间，不包含依赖等待、I/O 延迟等前置开销，所以实际影响可能比显示值更大。
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
确认关键路径上的真实瓶颈，用 systemd-analyze critical-chain
systemd-analyze critical-chain 展示的是从启动起点到 default.target（或 graphical.target）的最长依赖路径，每一步的时间是“该 unit 自身启动耗时”，不包含上游等待时间——这点最容易误解。
- 如果链条末端是
NetworkManager-wait-online.service，但blame显示它只花了 0.2s，而链条里上一级显示 +6.7s，说明瓶颈不在它自己，而在它的依赖（比如network-pre.target或sysinit.target） - 若想聚焦某个服务，可运行
systemd-analyze critical-chain docker.service，看它被谁卡住 - 该命令只显示
active状态的单元；被跳过（如ConditionPathExists不满足）或disabled的服务不会出现
别只盯着 blame 排名第一的服务改，它可能只是个“背锅侠”——critical-chain 才告诉你谁才是链路上那个真正卡住的节点。
可视化验证并行与阻塞，用 systemd-analyze plot
当 blame 和 critical-chain 结果有冲突，或者你想确认某几个服务是不是真在串行等待，就导出 SVG 图：systemd-analyze plot > boot.svg，然后用浏览器打开。
- 图中横轴是时间，纵轴是 service 名，每条色块代表该 unit 的启动区间
- 明显拉长的空白间隙，说明前面某个 unit 在阻塞后续并行启动（比如一个
.mount卡住，导致整条local-fs.target链都停住） - 多个长条服务横向堆叠，说明它们确实是并行跑的，优化其中任一个对总耗时影响有限
这张图不是锦上添花的装饰，而是唯一能交叉验证“依赖链是否真被阻塞”的手段——很多看似耗时的服务，其实根本不在关键路径上，靠图一眼就能排除。
