WSL启动慢问题分析与修复

WSL 启动要等 2 分钟？八成是这个服务，一条命令修复

环境：Windows 11 + WSL2（Ubuntu-22.04，systemd 已启用）。修复前冷启动 ~2min14s，修复后 ~1s。

TL;DR：直接抄作业

bash 复制代码

wsl -u root systemctl mask systemd-networkd-wait-online.service
wsl --shutdown   # 下次启动生效

就这两步。原理和排查过程往下看。

先确认你是不是同类问题

症状自查，满足任意两条基本就是：

打开 WSL / Windows Terminal 后要"转圈"1~2 分钟才出命令提示符
/etc/wsl.conf 里有 systemd=true
启动慢的是冷启动 （开机后第一次、或 wsl --shutdown 之后），而不是每个新终端窗口都慢

一条命令确诊：

bash 复制代码

systemd-analyze blame | head -5

如果 systemd-networkd-wait-online.service 排第一、耗时约 2 分钟 ------ 就是它，继续往下抄作业。

如果排第一的是别的东西（比如 snapd、plymouth、某个数据库服务），本文的排查方法同样适用，只是屏蔽对象换一下。

根因：一个在 WSL 里永远等不到的服务

systemd-networkd-wait-online.service 在正常 Linux 上的职责是网络就绪守门员：它阻塞等待所有网卡配置到"在线"状态，再放行 Nginx、数据库这类依赖网络的服务启动，避免它们在无网状态下起来就报错。

问题在于：WSL 的网卡（eth0）是 Windows 侧虚拟机管理器配好的，根本不经过 systemd-networkd 。这个守门员永远等不到"网络就绪"的信号，只能干等满默认的 2 分钟超时才放行。

所以每次冷启动，你都白等一个啥也没干的服务超时。它占了全部启动时间的 99%：

复制代码

2min 220ms  systemd-networkd-wait-online.service   ← 就是它
  1.093s    snap.lxd.activate.service
    971ms    snapd.seeded.service
    872ms    snapd.service
    ...

在 WSL 里网络由 WSL 自己管理，这个服务纯属多余，屏蔽（mask）没有任何副作用。

修复与验证

bash 复制代码

# 屏蔽（比 disable 彻底，连依赖拉起都挡住）
wsl -u root systemctl mask systemd-networkd-wait-online.service

# 冷启动一次
wsl --shutdown
wsl systemd-analyze

预期输出类似 Startup finished in 1.2s (userspace) ------ 完事。

回滚方式（万一以后需要）：

bash 复制代码

sudo systemctl unmask systemd-networkd-wait-online.service

附赠：再省 2 秒（可选）

snapd 三件套（snapd.service / snapd.socket / snap.lxd.activate.service）合计约 2 秒。WSL 里一般用 apt 装软件，snap 基本闲置。先确认没在用：

bash 复制代码

snap list   # 列表里只有 core20 / lxd / snapd 等系统自带包 = 没在用

确认后禁用：

bash 复制代码

wsl -u root systemctl disable snapd.service snapd.socket snap.lxd.activate.service

# 以后想用 snap 时恢复：
# sudo systemctl enable snapd.service snapd.socket snap.lxd.activate.service

排查过程复盘（通用方法论）

这次问题 5 分钟定位，靠的是固定套路，换任何"启动慢"都适用：

wsl -l -v + 检查 .wslconfig / /etc/wsl.conf
先排除资源配置问题（内存、CPU、systemd 开关），确认慢在哪一侧。
systemd-analyze
看 userspace 耗时。如果是 2 分钟级别，说明是 Linux 侧 systemd 服务在拖，不是 Windows/VM 的问题。
systemd-analyze blame + systemd-analyze critical-chain
按耗时排序直接锁定元凶，critical-chain 确认它在关键路径上。
评估该服务在 WSL 中是否必要
networkd-wait-online、snapd、ModemManager、plymouth 这些在 WSL 里通常都没用。
mask / disable 处理，保留回滚路径
多余且被依赖拉起的服务用 mask，普通自启用 disable，都随时可逆。

总结

	修复前	修复后
冷启动	~2min 14s	~1s
systemd-networkd-wait-online	干等 2 分钟超时	已屏蔽
snapd 三件套	~2s	已禁用

一句话：WSL 里 systemd 的"等网络"服务等不到信号、干耗 2 分钟超时，mask 掉它。