systemd-analyze time 直接显示 kernel、initrd、userspace 三阶段耗时，分别对应内核启动、initramfs 执行和 systemd 服务加载；blame --all --no-pager 揭示真实瓶颈（如 activating .mount 单元）；critical-chain 展示最长依赖路径，需结合 blame 判断真因；plot 生成 svg 时序图辅助分析。
直接运行 systemd-analyze time 就能知道总耗时和瓶颈在哪一阶段，不用猜、不用装额外工具。
看三阶段耗时分布用 systemd-analyze time
它输出类似 Startup finished in 718ms (kernel) + 1.713s (initrd) + 17.079s (userspace) = 19.511s，这三个值是连续阶段，不是并列：
-
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 --all --no-pager
systemd-analyze blame 默认只列出状态为 active 的 service 和 mount 单元，但真正拖慢启动的，往往是卡在 activating 或直接 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单元（检查/etc/fstab是否漏写nofail或x-systemd.timeout=5）
查真实依赖瓶颈用 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）在等网络通，而实际网络压根没配好 - 若链条中出现
dev-disk-by\x2duuid-xxx.device或initrd-switch-root.service，说明瓶颈在内核初始化、initramfs 解压/挂载、或根文件系统识别阶段——这些阶段 systemd 尚未接管，blame统计无效，此时应切换诊断路径：检查initramfs大小、确认磁盘 UUID 是否稳定、查看dmesg -t | head -20看内核日志起点
生成可视化时序图用 systemd-analyze plot
systemd-analyze plot > boot.svg 可导出 SVG 格式的启动时序图，直观展示服务依赖与并行/串行关系。图中横向为时间轴，每条色块代表一个 unit 的启动过程，重叠表示并行启动，空隙反映等待依赖。
- 需要系统已安装
graphviz（多数桌面发行版默认带，服务器版可能需手动装） - 若提示
Failed to get dependency graph，通常是权限不足，尝试加sudo（但通常不需要） - 重点观察那些耗时长且
WantedBy=multi-user.target或WantedBy=default.target的服务，它们更可能影响用户可见的启动终点
真正卡住启动的单元，往往藏在 blame --all 里，尤其是卡在 activating 状态的 .mount 单元——它们不会出现在默认 blame 列表里，却会把整条关键路径拖慢十几秒。
