直接用 systemd-analyze time 即可查看总耗时及 kernel、initrd、userspace 三阶段分布，精准定位瓶颈；再用 blame --no-pager --all 找出 failed 或 activating 的 .mount 单元，最后用 critical-chain 分析真实依赖路径。
直接用 systemd-analyze 一套命令就能完成，不用装额外工具，也不依赖第三方软件——所有主流 systemd 发行版（Ubuntu 16.04+、CentOS 7+、Debian 9+、Fedora、Arch 等）都自带。
看总耗时和瓶颈在哪一阶段
运行：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 扫描、RAID 初始化等。耗时高常见于
/etc/crypttab配置了交互式密码，或内核参数误加rd.md=0导致 RAID 设备识别失败 -
userspace：systemd 加载所有 unit 的总耗时，也是你感知“系统就绪”的主要区间。若占比超 80%，说明问题在服务层，下一步必须进
blame
注意：这个命令不包含 BIOS/UEFI 自检、GRUB 菜单停留、内核解压等前置时间，只反映 systemd 接管后的可测部分。
查真正拖慢启动的服务和挂载单元
运行：systemd-analyze blame --no-pager --all
-
--all强制列出所有已加载 unit，包括failed、activating、inactive状态——很多卡住启动的 .mount 单元（如拔掉的 USB 盘、不可达的 NFS）默认不会显示 -
--no-pager防止终端截断长名，尤其对 UUID 命名的设备（如dev-disk-by\x2duuid-1234567890abcdef.mount） - 重点关注耗时 ≥ 500ms 的条目，特别是：
—NetworkManager-wait-online.service（常因 DHCP 超时或 IPv6 RA 等待卡住）
—docker.service（镜像扫描阻塞）
— 各类.mount单元（检查/etc/fstab是否漏写nofail或x-systemd.timeout=5）
看真实依赖路径，而不是单个服务快慢
运行：systemd-analyze critical-chain
它展示的是从启动起点到 default.target（或 graphical.target）的最长依赖链，每一步的时间是该 unit 自身启动耗时，不含上游等待时间。
- 例如输出：
● default.target @17.079s<br> └─multi-user.target @17.079s<br> └─sshd.service @16.822s +257ms<br> └─network-online.target @16.821s<br> └─NetworkManager-wait-online.service @10.112s +6.709s
这说明 SSH 启动被网络就绪卡住，而真正耗时的是NetworkManager-wait-online.service前面的依赖（比如network-pre.target或systemd-networkd-wait-online.service），不是它自己慢 - 如果链条末端出现
dev-disk-by\x2duuid-xxx.device或initrd-switch-root.service，说明瓶颈在内核或 initramfs 阶段，blame统计已无效，需转向dmesg -t | head -20和ls -lh /boot/initramfs-$(uname -r).img检查
可视化启动流程，确认是否真串行
运行：systemd-analyze plot > boot.svg
用浏览器打开 boot.svg，可直观看到：
- 哪些服务是并行启动的，哪些被强制串行阻塞
- 是否存在大片空白（空闲期），说明某些依赖提前就绪但下游没及时触发
- 耗时长的服务是否真的处于关键路径上，还是只是“看起来慢”
配合 journalctl -u <em>service-name</em> -b 查日志，能快速定位卡点——比如 NetworkManager-wait-online.service 日志里出现 Timed out waiting for connectivity，就说明该等网络就绪环节可以优化或跳过。
