直接用 systemd-analyze 就能系统性诊断启动慢问题：time 查 kernel/initrd/userspace 三阶段耗时，blame --all --no-pager 找卡在 activating 或 failed 的慢 mount 单元，critical-chain 揭示最长依赖链中真实阻塞点，plot 生成 SVG 时序图可视化并行与阻塞关系。
直接用 systemd-analyze 就能系统性诊断启动慢的问题，它不依赖额外安装，所有 systemd 系统（Ubuntu 16.04+、CentOS 7+、Debian 9+、麒麟、UOS 等）都自带。关键不是看“哪个服务名字长”，而是分阶段查清时间在哪被吃掉、谁在等谁、哪些环节实际串行阻塞。
看三阶段耗时分布：kernel / initrd / userspace
运行：
systemd-analyze time
输出类似：
Startup finished in 1.234s (kernel) + 3.456s (initrd) + 12.789s (userspace) = 16.479s
这三段是严格串行的，顺序不能颠倒：
- kernel：从内核第一条指令执行到 systemd 进程（PID 1）创建完成；超 1s 要查 BIOS Fast Boot 是否开启、NVMe 驱动是否内置、Secure Boot 是否引发验证延迟
-
initrd：仅启用 initramfs 时存在，含 LVM 扫描、加密卷解锁等；高耗时常因
/etc/crypttab配置了交互式密码，或内核参数误加rd.md=0导致 RAID 初始化失败后无重试 -
userspace：systemd 加载所有 unit 的总耗时；若占比超 80%，说明瓶颈在服务层，下一步必须进
blame，而不是调 BIOS 或 GRUB
注意：该命令不统计 BIOS/UEFI 自检、GRUB 菜单停留、内核解压等前置时间，只反映 systemd 接管后的可测部分。
找真正拖后腿的服务：用 blame --all --no-pager
运行：
systemd-analyze blame --all --no-pager
--all 很关键——默认只列 active 状态的服务，但真正卡住启动的，常是处于 activating 或直接 failed 的 .mount 单元（比如 /mnt/backup.mount 指向已拔掉的 USB 盘，或 fstab 里写了不可达的 NFS 地址）。
--no-pager 防止终端截断长名（如 dev-disk-by\x2duuid-1234567890abcdef.mount 显示不全）。
重点关注耗时 ≥ 500ms 的条目，尤其是：
yuanfang-skills 的共享设计系统，提供 token CSS 变量、12+ 主题以及可复用的布局类型 HTML 块，供 yuanfang-html-image（以及 fu...）使用。
- NetworkManager-wait-online.service：常因 DHCP 超时卡住，默认等待 30 秒才放弃
- docker.service：启动时扫描本地镜像、初始化存储驱动，可能阻塞数秒
-
各种 .mount 单元：检查是否漏写
nofail或x-systemd.timeout=5
注意：blame 只统计 unit 从 start 到 running 的 active 时间，不包含依赖等待、I/O 延迟等前置开销，所以实际耗时常被低估。
查真实依赖瓶颈：critical-chain 揭示最长阻塞链
运行：
systemd-analyze critical-chain --no-pager
它展示的是从 default.target（或 graphical.target）向上回溯的**最长依赖路径**，每一步的时间是“该 unit 自身启动耗时”，不包含上游等待时间。
例如输出：
default.target @18.420s
└─multi-user.target @18.420s
└─ssh.service @15.200s +0.850s
└─network-online.target @12.105s
└─NetworkManager-wait-online.service @2.199s +10.000s
这里关键不是看 +10.000s 最大，而是看 @2.199s → @12.105s 这个近 10 秒的间隔——说明 NetworkManager-wait-online.service 启动很早，但它自己只花了 0.85 秒，却让下游等了 10 秒，问题大概率出在它依赖的上游（比如网络接口未就绪、DHCP 未响应）。
实用技巧：
- 想聚焦图形界面，用
systemd-analyze critical-chain graphical.target - 想查某个服务的完整依赖链，如
systemd-analyze critical-chain docker.service - 如果某 service 显示
not found，说明它根本没被加载（可能被 masked、disabled 或配置缺失）
可视化并行与阻塞关系：plot 生成 SVG 时序图
运行：
systemd-analyze plot > boot.svg
用浏览器打开 boot.svg，就能看到横轴为时间、纵轴为 unit 的交互式时序图：
- 绿色条表示成功启动，红色表示失败，灰色表示跳过
- 能一眼识别哪些服务本可并行却因依赖被堵死，哪些服务在空等上游
- 适合存档比对优化前后差异，也方便团队快速对齐问题
如果命令报错 Failed to get unit properties: Connection timed out，先运行 sudo systemctl restart systemd-journald 再试。
