systemd-analyze time 的三阶段分别指 kernel（内核初始化至 init 创建）、initrd（initramfs 阶段，含 LVM/加密卷处理）和 userspace（systemd 加载所有 unit 总耗时），其中 userspace 占比超 80% 时需用 blame --all 定位卡在 activating 或 failed 的 .mount 单元。
systemd-analyze time 显示的不是整机通电到登录的全程耗时，只是 systemd 接管后的三段计时；真正拖慢开机的单元，往往藏在 systemd-analyze blame --all 里，尤其是卡在 activating 状态的 .mount 单元。
systemd-analyze time 输出的三个阶段分别代表什么
运行 systemd-analyze time 得到类似这样的输出：
Startup finished in 1.234s (kernel) + 3.456s (initrd) + 12.789s (userspace) = 16.479s
-
kernel阶段：从内核第一条指令执行，到init进程被创建（不含 BIOS/UEFI、GRUB、内核解压）；超 1s 就该查 BIOS 中 Fast Boot 是否关闭、NVMe 驱动是否内置 -
initrd阶段：仅启用 initramfs 时出现，含 LVM 扫描、加密卷解锁等；高耗时常见于/etc/crypttab中配置了交互式密码提示，或内核参数误加了rd.md=0导致 RAID 初始化跳过失败重试 -
userspace阶段：systemd 加载所有 unit 的总耗时，占比 > 80% 说明问题在服务层，下一步必须用blame定位，而不是调 BIOS
systemd-analyze blame 默认不显示挂载失败的 .mount 单元
systemd-analyze blame 默认只列出状态为 active 的 unit，但很多启动慢的根因是 .mount 单元卡在 activating (start) 或直接 failed —— 比如 /etc/fstab 里写了已拔掉的 USB 设备、未响应的 NFS 服务器、或 UUID 错误的磁盘。
- 必须加
--all才能强制列出所有已加载 unit（含 failed/activating） - 必须加
--no-pager，否则终端宽度截断长名，比如dev-disk-by\x2duuid-1234567890abcdef.mount会显示不全 - 看到某
.mount耗时异常（如 10s+），先用systemctl status <unit>看其LoadState和ActiveState，再查journalctl -u <unit> -b确认是设备不可达还是权限/超时
NetworkManager-wait-online.service 高耗时别急着禁用
这个 service 经常排在 blame 前几名，但直接 systemctl disable NetworkManager-wait-online.service 可能导致依赖它的服务（如 docker、nfs-client）启动失败或网络不可用。
- 先看日志：
journalctl -u NetworkManager-wait-online.service -b，90% 场景是 DHCP 获取 IPv4 超时（默认 30s）或等待 IPv6 RA（Router Advertisement） - 临时绕过：在
/etc/NetworkManager/conf.d/10-no-wait.conf中加[main] dns=none; rc-manager=unmanaged并重启NetworkManager - 更稳妥的改法：编辑
/etc/systemd/system/NetworkManager-wait-online.service.d/override.conf，设ExecStart=/usr/bin/nm-online -s -q -t 5（把超时从 30s 缩到 5s）
critical-chain 显示的“最慢路径”不等于必须优化的点
systemd-analyze critical-chain 输出的是依赖树中最长的一条串行链，但它反映的是设计上的关键路径，不是性能瓶颈本身。例如：
- 某
mariadb.service在链上耗时 8s，但它可能只是因为multi-user.target依赖它，而其他服务并不等它——此时优化它对整体启动时间几乎没影响 - 真正要盯的是那些
@时间晚（启动晚）、+时间长、且被多个 target 依赖的单元，比如network-online.target或自定义的storage-ready.target - 用
systemctl list-dependencies --reverse <unit>查谁依赖它，比单看 critical-chain 更准
最容易被忽略的是：.mount 单元和 .target 单元的启动状态不会出现在默认 blame 列表里，而它们恰恰最常造成“启动卡住但看不出哪慢”的现象。每次排查前，先跑一遍 systemd-analyze blame --no-pager --all | head -30，比盯着 time 数字更有用。
