直接用 systemd-analyze time、blame --all --no-pager 和 critical-chain 三步即可定位启动瓶颈：time 显示 kernel/initrd/userspace 阶段耗时，userspace 占比超 80% 则问题在服务层；blame --all --no-pager 列出所有已加载单元（含 failed/activating .mount），重点关注 ≥500ms 条目；critical-chain 揭示最长依赖链，末端服务自身快但上游阻塞时，+xs 值才是真实瓶颈。
直接用 systemd-analyze 一套命令就能定位 systemd 服务的启动耗时瓶颈，不用装额外工具，所有主流发行版（Ubuntu 16.04+、CentOS 7+、Debian 9+ 等）都自带。
看整体阶段耗时分布
先运行：
systemd-analyze time
输出类似：
Startup finished in 718ms (kernel) + 1.713s (initrd) + 17.079s (userspace) = 19.511s
重点关注 userspace 阶段——它占总耗时超 80%，说明瓶颈就在 systemd 加载的服务层，下一步必须深入查服务本身；如果 kernel 或 initrd 偏高，则问题不在服务，而在固件、驱动或加密卷配置上。
使用 Kadence 主题作为 WordPress 项目的设计系统，涵盖设计令牌、布局系统、页头/页脚/导航设置以及页面/归档/单篇文章模板。
查最慢的已加载单元
运行：
systemd-analyze blame --no-pager --all
这个命令最关键：
• --all 强制列出所有已加载 unit，包括卡在 activating 或直接 failed 的 .mount 单元（比如 /etc/fstab 里写了拔掉的 U 盘、不可达的 NFS）
• --no-pager 防止终端截断长名，尤其对 UUID 命名的设备（如 dev-disk-by\x2duuid-...）
• 排在最上面的，就是当前拖慢启动的主力
重点关注耗时 ≥ 500ms 的条目：
• .service 类：NetworkManager-wait-online.service（常因 DHCP 超时卡 30s）、docker.service（镜像扫描阻塞）、apt-daily.service（自动更新检查）
• .mount 类：哪怕只显示 500ms，也要警惕——背后可能是 fstab 中未加 nofail 或 x-systemd.timeout=5 的挂载点
理清真实依赖链路
一个服务自己启动快，但上游卡住，它也会被拖慢。这时单看 blame 会误判。
运行：
systemd-analyze critical-chain --no-pager
它展示从 default.target 或 graphical.target 回溯的最长依赖路径。注意：
• 每步标注的 “+8.3s” 是它被上游阻塞的时间，比自身启动时间更有诊断价值
• 如果末端是 NetworkManager-wait-online.service，但它的 blame 时间只有 0.2s，说明问题出在它前面的网络就绪等待环节，不是它本身慢
辅助验证与定位
结合日志和可视化进一步确认：
• 查某服务日志：journalctl -u servicename.service -b，找 Timed out、failed to start 等关键词
• 生成时序图：systemd-analyze plot > boot.svg，用浏览器打开，看清哪些服务实际串行、哪些本可并行却被阻塞
• 对可疑服务查状态：systemctl status servicename.service，确认 LoadState、ActiveState 和触发原因
