systemd-analyze blame 默认按毫秒显示已激活服务启动耗时并倒序排列，但仅统计 active 时间、不包含依赖等待；需加 --all --no-pager 才能捕获 failed 或 activating 状态单元；配合 critical-chain 可识别真实瓶颈路径。
直接用 systemd-analyze blame 就能看到各服务的启动耗时，单位是毫秒，按从高到低排序，一眼就能找出拖慢开机的“大户”。
看整体阶段耗时分布
先运行：
systemd-analyze time
输出类似：
Startup finished in 842ms (kernel) + 1.321s (initrd) + 15.678s (userspace) = 17.842s
-
kernel：内核初始化到 systemd 进程（PID 1）创建完成 -
initrd：仅启用 initramfs 时存在，含加密卷解锁、LVM 扫描等 -
userspace：systemd 加载所有 unit 的总时间，占大头就说明问题在服务层
查具体服务或挂载单元耗时
默认命令只显示已成功激活（active）的服务：
systemd-analyze blame
但真正卡住启动的，往往是那些没起来的 .mount 单元或卡在 activating 状态的服务——它们不会出现在默认结果里。
要抓全，必须加两个参数：
systemd-analyze blame --no-pager --all
-
--all：列出所有已加载 unit，包括failed、activating、inactive状态 -
--no-pager：避免长名字（比如dev-disk-by\x2duuid-...mount）被截断
重点关注：
- 耗时 ≥ 500ms 的
.service（如NetworkManager-wait-online.service、docker.service） - 任何
.mount单元耗时异常 → 检查/etc/fstab是否指向已拔掉的设备或不可达的 NFS - 状态为
activating (start)的条目 → 用systemctl status <unit>查日志定位卡点
看真实依赖瓶颈在哪
blame 只告诉你“谁花的时间长”，但未必是它本身慢。比如一个服务只花 200ms，却因上游卡住，在关键路径上显示 +8s。
这时用：
systemd-analyze critical-chain
它展示的是从启动起点到 default.target（或 graphical.target）的最长依赖链，每一步的时间是该 unit 自身启动耗时，不是等待时间。
例如输出中出现：
● NetworkManager-wait-online.service @8.234s +6.7s └─network-online.target @8.234s └─NetworkManager.service @1.520s +120ms
说明 NetworkManager-wait-online.service 前面的依赖（比如网络接口未就绪）拖了它 6.7 秒，而不是它自己慢。
需要进一步查日志：
journalctl -u NetworkManager-wait-online.service -b
常见原因是 DHCP 超时、IPv6 RA 等待，而非服务代码问题。
不复杂但容易忽略
