最直接判断开机慢的服务是 systemd-analyze blame 中耗时最长的 .service，单位毫秒，仅统计自身 execstart 时间；常见拖慢项包括 docker.service、networkmanager-wait-online.service 等。
systemd-analyze blame 显示哪些服务拖慢了启动
开机慢，最直接的判断依据就是看哪个服务初始化耗时最长。systemd-analyze blame 会按耗时从高到低列出所有已启动的 unit（主要是 .service），单位是毫秒。它只统计该 unit 自身的 ExecStart 执行时间，不包含依赖项或并行等待开销。
常见拖慢项包括：docker.service（镜像加载）、NetworkManager-wait-online.service（等网络就绪）、apt-daily.service（自动更新检查）、某些硬件驱动模块加载（如 bluetooth.service 或 ModemManager.service）。
执行前确保系统已完整启动一次（否则未运行的服务不会出现在结果里）：
systemd-analyze blame | head -n 15
注意：systemd-analyze blame 不显示 static 或 disabled 的 unit；若某服务被跳过（比如因条件失败），也不会计入。
systemd-analyze critical-chain 定位启动瓶颈链路
systemd-analyze critical-chain 展示的是“关键路径”——即从 graphical.target（或 multi-user.target）回溯到最早启动的、不可并行化的依赖链。这条链上的每个环节都会直接影响总启动时间。
它比 blame 更能揭示“为什么某个服务启动得晚”，例如：
-
NetworkManager-wait-online.service卡住，可能是因为network-online.target等待dhcpcd.service超时 -
docker.service启动慢，但它的关键前置可能是containerd.service，而后者又依赖sysinit.target中某个 udev 规则加载
常用命令：
systemd-analyze critical-chain
如果想聚焦某个具体服务的关键依赖链：
systemd-analyze critical-chain docker.service
注意：该命令默认只显示 active 的 unit；若某 service 因 WantedBy= 缺失或 ConditionPathExists= 不满足而未激活，它不会出现在链中。
systemd-analyze plot 生成可视化启动时序图
systemd-analyze plot 输出 SVG 格式的时序图，能直观看到服务启动顺序、重叠区间和阻塞点。适合快速识别“大量服务挤在某个时间点集中启动”或“某服务长期处于 activating 状态”。
生成后用浏览器打开即可：
systemd-analyze plot > boot-timeline.svg
图中横向是时间轴（单位 ms），每条横线代表一个 unit，颜色区分状态（绿色 active，黄色 activating，灰色 inactive）。关键观察点：
- 是否存在长空白间隙（说明系统在等某个事件，比如磁盘 I/O 或网络响应）
- 是否有大量 unit 在同一时刻从
activating变为active（可能触发资源争抢） -
basic.target和multi-user.target之间的跨度是否异常大
注意：plot 不显示未启动或 failed 的 unit；若系统启用了 systemd.analyze=1 内核参数，可捕获更细粒度的事件（如 udev settle），但默认不启用。
禁用/延迟非必要服务的真实影响与风险
看到耗时高的服务，别急着 systemctl disable。很多看似“慢”的服务其实承担关键职责：
-
apt-daily.service：禁用后安全更新不会自动检查，但可改用apt-daily-upgrade.timer延迟到空闲时段 -
NetworkManager-wait-online.service：禁用后桌面环境可能无法自动连接 Wi-Fi，但可改为systemctl mask并在桌面会话中手动触发网络就绪 -
bluetooth.service：若不用蓝牙，disable是安全的；但若配对过设备，mask更彻底（防止被其他服务间接拉起）
真正有效的优化常是调整依赖关系而非删除服务。例如让 docker.service 不等 network-online.target，而是依赖更轻量的 network.target：
sudo systemctl edit docker.service
填入：
[Unit] After=network.target Wants=network.target BindsTo=
然后重载：systemctl daemon-reload。这类修改必须验证是否破坏功能，尤其是涉及网络、存储或安全模块的服务。
启动耗时分析容易忽略的一点：SSD 寿命老化或 ext4 日志模式异常会导致 systemd-journald 初始化变慢，这种问题不会出现在 blame 前十，但会在 plot 图中表现为早期阶段整体右移。
