systemd-analyze blame --no-pager --all 按毫秒级耗时从高到低列出所有已加载 unit（含 failed/activating 状态），首项即最可能拖慢启动的服务或挂载单元；需结合 critical-chain 分析依赖链、journalctl 查日志、time 判断瓶颈阶段，才能准确定位真实原因。
直接用 systemd-analyze blame 就能看到开机自启任务的耗时排行——它按毫秒级启动时间从高到低列出所有已成功激活的 unit（主要是 .service 和部分 .mount），排在最上面的就是当前拖慢开机的主力。
看真实耗时排行：用 blame --no-pager --all
默认的 systemd-analyze blame 只显示状态为 active 的服务，会漏掉真正卡住启动的单元：
- 加 --all：强制列出所有已加载 unit，包括卡在 activating (start) 或直接 failed 的 .mount 单元（比如 /etc/fstab 里写了拔掉的 U 盘、不可达的 NFS）
- 加 --no-pager：避免终端截断长名，尤其对 UUID 命名的设备（如
dev-disk-by\x2duuid-...） - 命令组合：
systemd-analyze blame --no-pager --all | head -n 15，快速聚焦前 15 名
识别哪些条目值得重点查
耗时本身只是线索，关键看类型和上下文：
-
.service 类：重点关注 ≥ 1s 的，比如
NetworkManager-wait-online.service（常因 DHCP 超时卡 30s）、docker.service（镜像扫描阻塞）、apt-daily.service（自动更新检查） -
.mount 类：哪怕只显示 500ms，也要警惕。它背后可能是 fstab 中配置了未连接设备，且没加
nofail或x-systemd.timeout=5 -
kernel/initrd 相关条目：如
initrd-switch-root.service或dev-disk-by\x2duuid-*.device出现在 blame 前列，说明瓶颈不在 systemd 层，而在内核或 initramfs 阶段
别只盯单个耗时，要看依赖链
一个服务自己启动快，但上游卡住，它也会被拖慢。这时 systemd-analyze critical-chain 才是关键：
- 运行
systemd-analyze critical-chain --no-pager，查看从default.target或graphical.target回溯的最长依赖路径 - 如果链条末端是
NetworkManager-wait-online.service，但它的blame时间只有 0.2s，说明问题出在它前面的依赖（比如等网络接口就绪、等 DHCP 响应） - 链条中某步标注 “+8.3s”，这个增量就是它实际被上游阻塞的时间，比自身启动时间更有诊断价值
辅助验证：结合 time 和日志定位阶段
先用 systemd-analyze time 看整体分布：
- 如果 userspace 占总耗时超 80%，说明问题确实在服务层，blame 和 critical-chain 是主战场
- 如果 initrd 高（比如 >3s），重点查
/etc/crypttab是否设了交互式密码、initramfs 是否过大（ls -lh /boot/initramfs-$(uname -r).img） - 查具体服务原因：对高耗时项执行
journalctl -u servicename.service -b，看启动过程中的报错或等待日志
