systemd-analyze time 可直接分阶段查看启动耗时，无需额外工具；它输出 kernel、initrd、userspace 三段连续耗时，其中 userspace 占比超 80% 时需用 blame --all --no-pager 定位 activating 或 failed 的 .mount 单元及慢服务，再结合 critical-chain 追踪真实依赖瓶颈。
直接用 systemd-analyze 就能分阶段看清启动耗时，不用装额外工具，所有主流 systemd 系统（Ubuntu 16.04+、CentOS 7+、Debian 9+、统信UOS、麒麟OS）都自带。
看整体三阶段耗时分布：systemd-analyze time
运行命令：
systemd-analyze time
输出类似：
Startup finished in 842ms (kernel) + 2.105s (initrd) + 14.321s (userspace) = 17.268s
这三个值是连续阶段，不是并列关系：
- kernel：从内核第一条指令执行，到 systemd 进程（PID 1）创建完成。超 1s 要查 BIOS Fast Boot 是否开启、NVMe 驱动是否内置、Secure Boot 是否引发验证延迟
-
initrd：仅启用 initramfs 时存在，含 LVM 扫描、加密卷解锁、RAID 初始化等。耗时高常见于
/etc/crypttab配置了交互式密码，或内核参数误加rd.md=0导致设备识别失败 -
userspace：systemd 加载所有 unit 的总耗时，占总耗时超 80% 说明瓶颈在服务层，下一步必须进
blame
注意：它不包含 BIOS/UEFI 自检、GRUB 菜单停留、内核解压时间，只反映 systemd 接管后的可测部分。
查具体哪个服务拖慢了 userspace：systemd-analyze blame --all --no-pager
默认的 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 超时（默认 30s）或等待 IPv6 RA 卡住 -
docker.service：镜像扫描或 overlayfs 初始化阻塞 - 各类
.mount单元：检查/etc/fstab是否漏写nofail或x-systemd.timeout=5
理清真实依赖阻塞点：systemd-analyze critical-chain
运行命令：
systemd-analyze critical-chain
它展示的是从启动起点到 default.target（或 graphical.target）的最长依赖路径，每级显示的时间是“该 unit 自身启动耗时”，不包含上游等待时间。
例如输出中看到：
● graphical.target
└─multi-user.target
└─docker.service
└─network-online.target
└─NetworkManager-wait-online.service
若 NetworkManager-wait-online.service 在 blame 中只花 0.2s，但 critical-chain 显示它前面一级有 +12s，说明瓶颈不在它本身，而在它的依赖（比如网络根本没配通，或 network-pre.target 卡住了）。
可视化并行与阻塞关系：systemd-analyze plot
运行命令：
systemd-analyze plot > boot.svg
用浏览器打开生成的 boot.svg，可以直观看到：
- 哪些服务是真正串行执行的（一条线拉到底）
- 哪些服务被其他 unit 拖累（横向空白多、启动晚）
- 是否存在大量空闲时间（说明并行度低，可优化依赖）
配合 blame 前 5 名服务，在图中定位它们的实际启动窗口和前置等待，比单看数字更准。
