systemd-analyze time、blame、critical-chain 三命令组合可在5分钟内精准定位Linux启动瓶颈：time查kernel/initrd/userspace三阶段耗时；blame --all --no-pager找≥500ms的拖慢单元；critical-chain分析依赖链阻塞点。
Linux系统启动变慢时，必须快速定位是内核加载拖沓、initramfs卡住，还是某个服务在后台悄悄耗尽几十秒——systemd-analyze time、blame、critical-chain 三个命令组合使用，5分钟内就能锁定真实瓶颈，无需安装额外工具，所有 systemd 系统（Ubuntu 16.04+、CentOS 7+、Rocky 9、Debian 9+）均原生支持。
查看整体启动三阶段耗时
运行 systemd-analyze time，直接输出 kernel / initrd / userspace 三个连续阶段的耗时总和与分布。
注意：该命令不包含 BIOS/UEFI 自检、GRUB 菜单停留、内核解压等前置时间，只反映 systemd 接管后的可测部分。
若 kernel 阶段 > 1s，需检查 BIOS 中 Fast Boot 是否关闭、NVMe 驱动是否未内置；initrd 阶段偏高，大概率是 /etc/crypttab 配置了交互式密码或内核参数误加 rd.md=0 导致 RAID 初始化失败重试；userspace 占比超 80%，说明问题一定出在服务层，下一步必须进 blame，而不是调 BIOS。
找出最拖后腿的服务和挂载单元
执行 systemd-analyze blame --no-pager --all。
必须加 --all，否则会漏掉卡在 activating (start) 或已 failed 的 .mount 单元——比如 /dev/disk/by-uuid/xxx.mount 对应一个拔掉的 U 盘，它不显示在默认 blame 列表里，却会让关键路径整体延迟 8 秒以上。
必须加 --no-pager，避免终端宽度截断长服务名，例如带 UUID 的挂载单元会被截成 dev-disk-by\x2duuid-123...，根本看不出对应哪个设备。
重点关注耗时 ≥ 500ms 的条目：NetworkManager-wait-online.service（常因 DHCP 超时卡住）、docker.service（镜像扫描阻塞）、/mnt/nfs.mount（fstab 写了不可达 NFS 地址且没设 nofail）。
分析真实依赖瓶颈路径
第一步：运行 systemd-analyze critical-chain，查看从 default.target 回溯的最长依赖链。
第二步：观察链条末端服务，例如看到 NetworkManager-wait-online.service +6.7s，但它的 systemd-analyze blame 结果只有 0.2s，说明它自己很快，真正卡住的是上游 network-pre.target 或 dhcpcd.service 等前置依赖。
第三步：若想聚焦某服务（如 docker.service），运行 systemd-analyze critical-chain docker.service，输出中顶部是最后启动环节，底部是最早启动的前置依赖，整条链不可并行化，任一环节延迟都会拉长总启动时间。
注意：critical-chain 默认只显示 active 状态的单元；被跳过（如 ConditionPathExists 不满足）或 disabled 的服务不会出现。
生成可视化启动时序图
运行 systemd-analyze plot > boot-time.svg。
这一步操作起来很简单，直接把生成的 SVG 文件用浏览器打开就行。
图表能清晰展示哪些服务是串行阻塞、哪些是并行启动、哪些服务之间存在空闲等待窗口——比如发现 containerd.service 启动前有长达 4.2 秒的空白期，说明它的前置依赖（如 sysinit.target 中某个 udev 规则）尚未完成，而非 service 本身慢。
