systemd-analyze time 的三阶段分别指 kernel（内核初始化至 systemd 进程创建）、initrd（initramfs 阶段，含 lvm/加密卷处理）和 userspace（systemd 加载所有 unit 总耗时），其中 userspace 占比超 80% 时需用 blame --all 定位卡在 activating 或 failed 的 .mount 单元。
直接看总耗时和阶段分布，用 systemd-analyze time 就够了——它不测 BIOS/GRUB，但能准确定位 kernel、initrd、userspace 三段里哪一段在拖慢你。
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
systemd-analyze blame 默认漏掉挂载单元和失败服务
systemd-analyze blame 默认只列出状态为 active 的 service 和 mount 单元，但真正卡住启动的，往往是那些没成功挂载的 .mount 单元（比如 fstab 里写了已拔掉的 USB 盘、不可达的 NFS 地址），或者卡在 activating (start) 状态的服务。
- 必须加
--all参数才能看到 failed、activating、inactive 等所有已加载 unit：systemd-analyze blame --all - 加
--no-pager防止终端截断长名字，尤其对 UUID 命名的设备（如dev-disk-by\x2duuid-xxx.mount） - 重点关注耗时 ≥ 1s 的条目，特别是
NetworkManager-wait-online.service（常因 DHCP 超时或 IPv6 RA 等待卡住）、docker.service（镜像扫描阻塞）、以及各种.mount单元（检查/etc/fstab是否漏写nofail或x-systemd.timeout=5）
critical-chain 显示的是依赖路径，不是服务自身耗时
systemd-analyze critical-chain 输出的是当前 target（默认 multi-user.target）最长的一条串行依赖链，每级显示的时间是“该 unit 自身启动耗时”，不包含上游等待时间。容易误解成“它慢所以要优化它”，其实它可能自己很快，只是上游卡住了。
- 如果链条末端是
NetworkManager-wait-online.service，但blame显示它只花了 0.2s，而 critical-chain 里它前面一级显示 +6.7s，说明瓶颈在它的依赖（比如network-pre.target）上，实际网络压根没配好或网卡未就绪 - 某 service 显示
not found，代表它根本没加载——可能是被systemctl mask、WantedBy=写错，或 unit 文件语法错误导致解析失败 - 图形界面环境请显式指定：
systemd-analyze critical-chain graphical.target，否则看不到桌面相关链路
真正难搞的从来不是单个耗时长的服务，而是那些不报错、不失败、却默默卡在 activating 状态的 mount 单元或第三方服务——它们不会出现在默认 blame 列表里，也不会触发 journal 报错，但会让整个关键路径凭空多出几秒甚至十几秒延迟。
