排在 systemd-analyze blame 输出最上方的服务即最可能拖慢开机的元凶；它按毫秒级耗时从高到低列出已成功激活的 .service 单元，仅统计 ExecStart 自身执行时间，不包含依赖等待，并需结合 critical-chain、systemctl status 和 journalctl 验证真实瓶颈。
直接看 systemd-analyze blame 的输出，排在最上面的服务就是最可能拖慢开机的元凶。
用 systemd-analyze blame 找出耗时最长的服务
这条命令会按毫秒级启动耗时从高到低列出所有已成功激活的 .service 单元：
- 运行 systemd-analyze blame --no-pager，避免卡在分页器里
- 重点关注耗时超过 2 秒的项，比如 5.234s NetworkManager-wait-online.service 或 3.890s docker.service
- 注意：它只统计服务自身 ExecStart 的执行时间，不包含等待依赖或并行延迟
- 失败、被跳过（如 ConditionPathExists 不满足）或 disabled 的服务不会出现
用 systemd-analyze critical-chain 看清依赖链条
单看 blame 只知道“谁慢”，critical-chain 才能解释“为什么慢”：
- 运行 systemd-analyze critical-chain，查看从 default.target 到 multi-user.target 的最长依赖路径
- 输出中顶部是最后启动但最耗时的环节，底部是最早启动的前置依赖
- 如果链顶是 NetworkManager-wait-online.service，大概率是网络未就绪导致卡住
- 可指定服务查其路径，例如 systemd-analyze critical-chain sshd.service
结合 systemctl status 和 journalctl 验证问题
确认服务状态和日志，避免误判：
- 对可疑服务运行 systemctl status 服务名，看 Active: 是否为 activating (start) 卡住
- 查最近启动日志：journalctl -u 服务名 --since "1 hour ago"
- 若服务显示 not found，说明它根本没被加载（可能被 masked、disabled 或配置缺失）
别漏掉 fstab 和主机名这类隐藏陷阱
有些“慢”不是服务本身慢，而是系统在傻等：
- 检查 /etc/fstab：用 sudo blkid 和 findmnt -D 核对 UUID 和设备是否存在；对非关键挂载加 nofail 或 x-systemd.automount
- 检查主机名解析：运行 hostname 得到主机名，再确认 /etc/hosts 里有对应行，例如 127.0.0.1 myhost；缺这行，SSH、Postfix 等服务会 DNS 超时卡住
