systemd-analyze 是 systemd 启动分析第一工具，直接读取时间戳给出总耗时（如 kernel 2.1s + userspace 18.3s），定位瓶颈在用户空间；配合 blame、critical-chain、plot 和 journalctl 可精准识别等待依赖、配置错误等深层原因。
systemd-analyze 能直接告诉你总耗时和瓶颈在哪
Linux 用 systemd 启动后，systemd-analyze 就是第一把尺子——它不猜、不推断，直接读取启动日志里的时间戳。运行一次，你就知道“内核花了多久”“用户空间拖了多久”，比如输出 kernel 2.1s + userspace 18.3s，那问题基本就在用户空间那一堆服务里。
-
systemd-analyze：只看总耗时，定位大方向 -
systemd-analyze blame：列出每个已启动单元的耗时，从高到低排，重点关注 >500ms 的项（如NetworkManager-wait-online.service或你自定义的myapp-init.service） -
systemd-analyze critical-chain：不是看单个服务多慢，而是看哪条依赖链最长——比如multi-user.target → docker.service → network-online.target → NetworkManager-wait-online.service，真正卡点往往在链尾那个“等网络就绪”的环节
别只盯着“慢服务”，先查清楚它为什么慢
很多服务本身启动很快，但被卡在等待上。比如 NetworkManager-wait-online.service 默认会等 DHCP 获取 IP 成功或超时（常为 30 秒），而你的机器可能压根没连网，或者只是插了网线但没配 DHCP 服务器——它就干等满格。
- 用
journalctl -u NetworkManager-wait-online.service -b看日志，找Timed out waiting for connectivity这类提示 - 检查主机名解析是否失败：
hostname输出mydesk，但/etc/hosts里没有127.0.0.1 mydesk？SSH、Postfix 等服务就会 DNS 超时卡住几秒到十几秒 -
/etc/fstab里有没有带_netdev却没加nofail的 NFS 条目？一个挂载失败，整个启动可能就挂住
禁用服务前，先确认它真没被调用过
看到 bluetooth.service 耗时 2.4s，别急着 systemctl disable。有些服务虽不手动启，却被其他单元隐式拉起（比如某个蓝牙音频 profile 依赖它），盲目禁用可能导致后续功能异常。
- 先查状态：
systemctl status bluetooth.service看Loaded行是否含disabled，再看Active是不是inactive (dead) - 再查历史调用：
journalctl -u bluetooth.service --since "7 days ago" | grep -i "started\|activating"，如果 7 天内完全没记录，才大概率可安全禁用 - 禁用后仍被拉起？说明有其他服务
Wants=或Requires=它，这时该用systemctl mask bluetooth.service（解除用unmask）
画图比看数字更直观：用 plot 生成启动时间线
systemd-analyze plot > boot.svg 生成的 SVG 图，能一眼看出哪些服务并行、哪些被阻塞、哪些在空等——比如一条横跨 15 秒的空白长条，后面紧跟着 docker.service，那基本就是它前面某个 After=xxx 单元在傻等，而不是 Docker 自身慢。
- 打开
boot.svg（用浏览器就行），鼠标悬停看每个矩形块的精确起止时间 - 重点找“长条+空白”组合：空白代表等待，长条是实际工作，两者之间就是真正的卡点
- 注意颜色区分：灰色是未启用单元，蓝色是并行启动，红色是串行依赖——别被并行块的长度误导，关键路径永远是红色那条最顶上的链
真正难的不是找到哪个服务慢，而是判断它慢是因为自身逻辑重，还是上游没给信号、下游没释放资源、或者配置里写了错的 After= 却漏了 Wants=。这些细节，plot 和 critical-chain 一起看才看得清。
