systemd-analyze 是所有主流 systemd 系统自带的唯一诊断工具，通过 time、blame、critical-chain 和 plot 四个子命令精准定位启动瓶颈：time 分阶段显示耗时，blame 列出实际启动的 unit 耗时，critical-chain 揭示最长依赖路径，plot 可视化并行与阻塞关系，需结合多次重启与上下游分析才能准确定因。
systemd-analyze 是唯一需要的工具，不用装额外包，所有 systemd 系统（Ubuntu 16.04+、CentOS 7+、Debian 9+、麒麟OS、统信UOS）都自带。它不查“开机启动项列表”，而是查「实际启动了哪些 unit 及各自耗时」——这才是定位慢启动的真实依据。
systemd-analyze time 看总耗时与阶段分布
直接反映从硬件上电到桌面就绪的完整链条，不是“服务数”，而是“时间在哪被吃掉”：
-
firmware和loader阶段高，说明 BIOS/UEFI 设置、Secure Boot 或 GRUB 超时配置有问题 -
kernel高，常见于内核参数不当（如rd.driver.pre加载顺序错）、驱动缺失或硬件自检卡住 -
initrd高，多因加密卷解锁交互、LVM/RAID 设备扫描超时，或 initramfs 缺少必要模块（如nvme或dm-crypt） -
userspace高，才是 service 层优化主战场；注意graphical.target reached after的值，它才是你感知到“桌面出来了”的真实耗时
systemd-analyze blame 找真正拖后腿的服务
它只列出「本次成功启动」的 unit，失败、跳过、被 mask 的都不会出现——别误以为没列出来就安全：
PyCharm 2026.2.0.1 Linux版
下载
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
- 加
--no-pager防止卡在less：运行systemd-analyze blame --no-pager - 重点关注耗时 ≥ 1s 的
.service，例如：NetworkManager-wait-online.service（等 DHCP 超时）、docker.service（镜像扫描）、plymouth-quit-wait.service（等待开机动画退出） - 也留意
.mount单元，比如/mnt/nfs.mount耗时 8s，大概率是 fstab 里写了不可达 NFS 地址且没设nofail,x-systemd.timeout=5 - 某些服务含
RandomDelaySec=，单次结果波动大，建议重启 2–3 次再比对中位数
systemd-analyze critical-chain 锁定阻塞链路
一个服务自己快，但上游卡住，它也会被拖慢——critical-chain 显示的就是这条最长依赖路径，每级时间是「该 unit 自身启动耗时」，不包含上游：
- 默认跑
systemd-analyze critical-chain，看是否落到multi-user.target；图形界面用systemd-analyze critical-chain graphical.target - 如果链条末端是
NetworkManager-wait-online.service，且它自身blame耗时仅 0.2s，但链条里显示 +6.7s，说明它前面的依赖（如network-pre.target）在等网络通，而实际网络压根没配好 - 某 service 显示
not found，代表它根本没加载——可能是被systemctl mask、WantedBy=写错，或 unit 文件语法错误（可用systemd-analyze verify xxx.service检查）
systemd-analyze plot 生成 SVG 时间线图
文字命令看不清并行/串行关系？这张图能一眼揪出问题：
- 必须重定向保存：
systemd-analyze plot > boot.svg，然后用浏览器打开；终端直接执行只会刷一堆 XML - 图中横向长条越长，该 unit 实际运行越久；前方大片空白，说明它在等上游；多个条并排，说明它们是并行启动的
- 若发现某个
.service条块颜色异常（如黄色警告或红色失败），右键查看其属性可定位具体错误日志位置 - 报
Failed to get unit properties: Connection timed out，先运行sudo systemctl restart systemd-journald再试
真正容易被忽略的是：userspace 阶段里，blame 排名靠前的服务未必是根源，它可能只是“最后一个等的人”。关键得用 critical-chain 往上翻两层，看是谁在它前面卡住不动——比如 sshd.service 启动慢，往往不是 sshd 本身问题，而是它依赖的 systemd-tmpfiles-setup.service 因磁盘满或权限错卡死。
