systemd-analyze time 直接显示 kernel、initrd、userspace 三阶段耗时，但不含 BIOS/UEFI、GRUB、内核解压等前置时间；kernel 超 1s 查固件设置与驱动，initrd 高耗时查加密/LVM 配置，userspace 占比超 80% 需用 blame --all 定位卡在 activating 或 failed 的 .mount 单元。
systemd-analyze time 能直接看到三阶段耗时，但不含 BIOS/GRUB 时间
运行 systemd-analyze time 就能立刻知道 kernel、initrd、userspace 各花了多久，比如输出 Startup finished in 718ms (kernel) + 1.713s (initrd) + 17.079s (userspace) = 19.511s。这个总和不是“从按下电源键到能登录”的全程时间，它只从内核初始化完成、systemd 进程（PID 1）启动开始计时，不包括 BIOS 自检、UEFI 延迟、GRUB 菜单停留、内核镜像解压等前置环节。
所以如果你测出来 kernel 阶段 > 1s，问题大概率在固件层：检查 BIOS 是否关闭了 Fast Boot、NVMe 驱动是否编译进内核而非模块、Secure Boot 是否触发额外签名验证；initrd 耗时高，先看 /etc/crypttab 是否配置了交互式密码，或内核参数里有没有误加 rd.md=0 导致 RAID 初始化跳过失败重试。
systemd-analyze blame --all 才能看到真正卡住的挂载单元
systemd-analyze blame 默认只显示状态为 active 的 service 和 mount 单元，但拖慢启动的往往藏在别处：
- 卡在
activating (start)状态的.mount单元（比如/etc/fstab里写了已拔掉的 USB 盘、不可达的 NFS 地址） - 直接
failed的设备单元（如dev-disk-by\x2duuid-xxx.device因 UUID 不匹配反复超时） - 名字极长的 UUID 设备（终端默认分页会截断，看不到完整名）
必须用 systemd-analyze blame --no-pager --all 才能强制列出所有已加载 unit。重点关注耗时 ≥ 500ms 的条目，尤其是 NetworkManager-wait-online.service（常因 DHCP 超时卡 30s）、docker.service（镜像扫描阻塞）、以及任何 .mount 单元——对后者，立刻执行 systemctl status <code>unit-name 查 LoadState 和 ActiveState，再用 journalctl -u <code>unit-name -b 确认是设备不可达、权限不足，还是超时值太小。
critical-chain 显示的是最长依赖链，不是服务自身慢
systemd-analyze critical-chain 输出的是从启动起点到 default.target 的**最长串行依赖路径**，每一步的时间是该 unit 自身的 active 时间，不包含它前面依赖项的等待时间。容易误判成“这个 service 慢”，其实它可能只花了 0.2s，但上游卡了 6s。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
典型例子：critical-chain 末端是 NetworkManager-wait-online.service，而 blame 显示它只耗时 200ms，说明瓶颈不在它本身，而在它的依赖（比如 network-pre.target 或 systemd-networkd-wait-online.service）——此时应查 journalctl -u NetworkManager-wait-online.service -b，90% 场景是 IPv6 RA 等待或 DHCPv4 获取超时。
如果链条中出现 dev-disk-by\x2duuid-xxx.device 或 initrd-switch-root.service，说明问题发生在 initramfs 或内核阶段，blame 已无效，得切去查 dmesg -t | head -20 和 ls -lh /boot/initramfs-$(uname -r).img。
历史启动记录要用 journalctl --list-boots，不是 uptime
uptime -s 和 who -b 只返回当前这次启动的时间，没法回溯。要查上次、上上次甚至更早的启动耗时，必须用 journalctl --list-boots ——它列出所有 boot ID、起止时间，格式为：
-1 abcdef12 Wed 2026-07-01 08:22:15 CST — Wed 2026-07-05 14:33:42 CST 0 12345678 Wed 2026-07-05 14:34:01 CST — still running
其中 0 是当前启动，-1 是上一次。拿到 boot ID（如 abcdef12）后，可精确分析那次启动：systemd-analyze time --boot-id=abcdef12、systemd-analyze blame --boot-id=abcdef12 --all。注意：这些命令依赖 journald 日志保留策略，若 /var/log/journal 被清理或 SystemMaxUse 设得太小，旧 boot 记录可能丢失。
