systemd-analyze 可精准定位启动瓶颈：先用 time 分三段判断问题方向，再用 blame 找耗时单元，critical-chain 追踪关键路径，plot 生成可视化时间线，verify 检查配置合规性，最后重启实测优化效果。
直接用 systemd-analyze 系列命令就能定位引导慢在哪一环，不用猜、不靠经验——它读的是真实启动日志里的精确时间戳。
看总耗时和阶段分布
systemd-analyze time 是第一步。它把启动拆成 kernel、initrd、userspace 三段，帮你快速判断问题大方向：
- kernel 耗时高（比如 >1.5s）：查 BIOS/UEFI 是否开启 Fast Boot，NVMe 驱动是否内置，Secure Boot 是否引发额外验证
- initrd 耗时高：重点看加密卷解锁（
/etc/crypttab）、LVM/RAID 扫描是否超时，或内核参数误禁了必要模块（如rd.md=0） - userspace 占比超 80%：说明瓶颈在服务层，下一步必须用
blame
揪出最拖后腿的单元
systemd-analyze blame --no-pager --all 能列出所有已加载单元（包括 failed 和 activating 状态），不只是“跑完”的服务：
- 重点关注耗时 >500ms 的 .service（如
NetworkManager-wait-online.service、docker.service） - 别漏掉 .mount 单元——它们常对应
/etc/fstab中不可达设备（拔掉的 U 盘、未响应的 NFS 服务器） - 看到状态卡在
activating (start)，说明依赖没满足或初始化阻塞，要用systemctl status [unit]查具体原因
追踪关键依赖链
systemd-analyze critical-chain 显示决定总耗时的最长串行路径，比如：
multi-user.target → sshd.service → network-online.target → NetworkManager-wait-online.service
真正卡点往往在链尾。这时不能只盯着 service 本身，要查它为什么慢：
- 对
NetworkManager-wait-online.service，运行journalctl -u NetworkManager-wait-online.service -b，找Timed out waiting for connectivity这类提示 - 检查主机名能否解析：
hostname输出的值是否在/etc/hosts里有对应条目？否则 SSH、Postfix 等服务会 DNS 超时卡住 - 确认
/etc/fstab中远程挂载是否加了_netdev和nofail，否则可能默认等满 90 秒
验证和可视化辅助
有些问题光看文字不够直观：
- 生成 SVG 时间线图：
systemd-analyze plot > boot.svg，打开后能看到哪些服务并行、哪些被阻塞、哪些在空等 - 检查单元配置是否合规：
systemd-analyze verify docker.service，可发现循环依赖、缺失WantedBy=或错误使用After=导致顺序错乱 - 优化后务必重启实测：
systemd-analyze time对比前后总耗时，再用blame确认目标单元是否消失或耗时显著下降
