systemd-analyze blame 显示的单位是毫秒，但仅统计 unit 从 start 到 running 的 active 时间，不包含依赖等待、i/o 延迟等前置开销，因此实际耗时常被低估。
systemd-analyze blame 显示的单位是毫秒，但实际耗时可能被低估
systemd-analyze blame 输出每一项服务的“启动耗时”，但它只统计从该 unit 进入 start 状态到进入 running 状态之间的时间（即 active 时间），不包含依赖等待、并行阻塞、I/O 延迟或内核模块加载等前置开销。比如 NetworkManager.service 显示耗时 850ms，但若它卡在等待 sysinit.target 下游的 udev-settle.service 完成，这部分不会计入它的 blame 时间。
实操建议：
- 先运行
systemd-analyze blame快速定位“表面最慢”的几个服务 - 对排在前 5 的服务，用
systemd-analyze plot > boot.svg导出时序图，观察它们是否真正串行，还是被其他 unit 拖累 - 重点关注那些耗时长且
WantedBy=multi-user.target或WantedBy=default.target的服务，它们更可能影响用户可见的启动终点
blame 结果里出现 kernel 或 initrd 相关条目说明问题不在 systemd 本身
如果 systemd-analyze blame 输出中出现类似 dev-disk-by\x2duuid-xxx.device、initrd-switch-root.service 或 kernel-command-line 这类条目，说明瓶颈在内核初始化、initramfs 解压/挂载、或根文件系统识别阶段——这些阶段 systemd 尚未接管，blame 统计无效。
此时应切换诊断路径：
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
- 检查 initramfs 大小：运行
ls -lh /boot/initramfs-$(uname -r).img，超 50MB 容易拖慢解压 - 确认磁盘 UUID 是否稳定：
blkid和/etc/fstab中的 UUID 是否一致，不一致会导致dev-disk-by\x2duuid-*.device超时重试 - 查看内核日志起点：用
dmesg -t | head -20看第一条时间戳，对比systemd-analyze time中的 “firmware” 和 “loader” 阶段耗时
想看完整启动链路，不能只靠 blame，得配合 critical-chain
systemd-analyze critical-chain 展示的是从启动开始到某个 target（默认 default.target）的**最长依赖路径**，每一步都含实际耗时，比 blame 更能反映“为什么启动慢”。例如它可能显示：default.target → multi-user.target → sshd.service → network-online.target → NetworkManager-wait-online.service，而最后一步耗时 12s——这说明 SSH 启动被网络就绪卡住，而非 sshd.service 本身慢。
实用技巧：
- 加
--no-pager避免分页截断：systemd-analyze critical-chain --no-pager - 指定 target 查关键路径：
systemd-analyze critical-chain graphical.target（桌面环境） - 对比两个 target 的路径差异，能快速判断桌面 vs CLI 启动慢在哪一环
blame 排序不准？注意 --order 和 --reverse 参数的误用场景
systemd-analyze blame 默认按耗时降序排列，但如果你手动加了 --order 或 --reverse，结果会变成按 unit 名字字母序或反序，完全失去性能分析意义。常见错误是复制网上命令时没删掉冗余参数，比如：systemd-analyze blame --order —— 这个 --order 实际被忽略（因为没指定值），但容易让人误以为排序逻辑变了。
安全做法：
- 始终用原始命令：
systemd-analyze blame - 需要过滤时用管道：
systemd-analyze blame | grep -E "(docker|nginx|mysql)" - 导出为 CSV 分析：用
systemd-analyze blame --json=short（systemd v249+）再交给 awk 或 jq 处理
/proc/cmdline 或重做 initramfs，不是改 systemd service 文件能解决的。
