systemd-analyze blame 按耗时从高到低列出已成功启动的 unit，首项常为瓶颈；critical-chain 展示最长依赖路径定位卡点；plot 生成 svg 时序图可视化并行与阻塞。
systemd-analyze blame 看哪些服务拖慢启动
开机慢，不是靠猜，是看谁真在后台卡着。直接运行 systemd-analyze blame，它会按耗时从高到低列出所有已启动的 unit（主要是 .service），排第一的那个，八成就是瓶颈。
注意：只显示「已成功启动」的服务；失败或跳过的不会出现。如果某个服务明明该启却没启，它不会出现在列表里，别误以为它不重要。
- 加
--no-pager避免卡在 less 里：systemd-analyze blame --no-pager - 想看前 10 个最慢的？用
systemd-analyze blame | head -n 10 - 某些服务启动时间含“随机延迟”（比如
RandomDelaySec=），实际每次启动可能波动较大，别单看一次结果就下结论
systemd-analyze critical-chain 定位启动依赖链路
一个服务慢，未必是它自己写得差，可能是它等的上游太慢。用 systemd-analyze critical-chain 能打出从 default.target 到最终目标（比如 multi-user.target）之间最耗时的那条依赖路径。
输出里每行是一个 unit，时间是它自身启动耗时（不含依赖项），箭头方向是依赖关系。关键看链条顶端那个单位——如果它是 NetworkManager-wait-online.service，大概率是网络没通导致卡住。
- 可指定具体服务查它的关键路径：
systemd-analyze critical-chain sshd.service - 若某 service 显示
not found，说明它根本没被加载（可能被 masked、disabled 或配置文件缺失） - 注意
critical-chain不等于完整依赖图，它只取“最长路径”，其他并行分支不会展开
systemd-analyze plot 生成启动时序 SVG 图
文字看不清依赖重叠和并行程度？systemd-analyze plot 输出一个 SVG，横轴是时间，每行是一个 unit，颜色区分状态（绿色=成功，红色=失败），能一眼看出哪些服务在抢资源、哪些被堵死。
适合发给同事快速对齐问题，也方便存档比对优化前后差异。但别直接在终端里打开——它输出的是 XML 内容，要重定向保存再用浏览器打开。
- 保存为文件：
systemd-analyze plot > boot.svg - 浏览器打开
boot.svg即可查看交互式图表 - 如果输出为空或报错
Failed to get unit properties: Connection timed out，说明 systemd-journald 没跑稳，先systemctl restart systemd-journald再试
禁用非必要服务前先确认依赖和用途
看到某个 service 耗时长就想 systemctl disable？小心踩坑。很多服务看似无关，实则被其他 unit 依赖（比如 ModemManager 可能被 NetworkManager Requires），盲目禁用会导致网络或登录失败。
真正安全的操作顺序是：先查依赖 → 再查是否真被使用 → 最后决定禁用还是 mask。
- 查谁依赖它：
systemctl list-dependencies --reverse --type=service xxx.service - 查它依赖谁：
systemctl list-dependencies --type=service xxx.service - 确认当前没在用：
systemctl is-active xxx.service（返回 inactive 才算空闲） - 禁用 ≠ 删除；如需彻底阻止启动，用
systemctl mask xxx.service（但恢复麻烦，慎用）
系统启动项不是越少越好，而是“该等的等，不该等的不等”。依赖关系和实际用途比启动耗时数字更关键。
