Docker Desktop 在 Windows 上启动失败，这个报错我这些年处理过不下几十次。最常见的就是那个红底白字的弹窗：Docker Desktop failed to start because virtualisation support wasn‘t detected，翻译过来就是“虚拟化支持未被检测到”。很多朋友第一次看到这句话，第一反应是去 BIOS 里开 VT-x，结果开了还是报错，折腾一晚上也没搞明白。其实虚拟化在 Windows 上不是一个开关能解决的，它是好几层东西叠在一起，任何一层出了问题，Docker 都起不来。
这篇文章我打算把这条链路完整拆一遍：从硬件虚拟化开关，到 Windows 功能组件，再到 WSL2 内核，最后是 Docker Desktop 自己的配置。无论你是刚接触 Docker 的新手，还是被这个报错卡了很久的老兵，沿着后面的流程走一遍，大概率能一次解决。
1. 这个报错到底在说什么：先搞清楚 Docker Desktop 的虚拟化依赖
1.1 同一句报错，背后的三种可能
“Virtualization support wasn't detected”这句话很笼统，Docker Desktop 启动时实际上做了一系列检查，只要有一项不合格，就会弹这个统一提示。根据我排错的经验，常见的诱因主要有三类：
第一类是 CPU 硬件虚拟化没开。Intel 的 VT-x 或者 AMD 的 SVM，很多品牌机出厂默认是关闭的，需要进 BIOS 手动打开。这种情况在旧电脑、办公电脑上非常常见。
第二类是 Windows 的虚拟化相关组件没装全。Docker Desktop 在 Windows 上不是直接跑在系统上的，它依赖 Windows 自带的虚拟化层。常见的报错代码 0x80370102 就属于这一类，系统提示“无法启动虚拟机，因为虚拟机监控程序未运行”，但你看任务管理器，CPU 虚拟化明明是“已启用”，这就让人很困惑。
第三类是 WSL 版本不对或者 WSL 内核太旧。新版 Docker Desktop 默认走 WSL2 后端，如果你的 WSL 还停留在 1 代，或者内核文件损坏，Docker 也会报虚拟化相关问题。这类问题往往被忽略，因为很多人根本不知道 Docker 和 WSL 还有这层关系。
你可以把 Docker Desktop 想成一个“包租公”，它自己不干活，而是要租一套叫“虚拟机”的房子，房子下面是硬件。包租公要正常营业，需要满足两个条件：房东（硬件 BIOS）同意把虚拟化能力租给它，物业（Windows 系统）把水电网络（Hyper-V / WSL 组件）全部接通。任何一个环节断掉，包租公都只能给你一个“营业失败”的通知，至于是哪一环坏了，它不会多说。
1.2 Windows 上 Docker 的两种后端：WSL2 与 Hyper-V
要理解排错方向，还得先知道 Docker Desktop 在 Windows 上其实有两条运行路线。
一条是 Hyper-V 后端。Hyper-V 是微软自家的虚拟机平台，Docker 会启动一个完整的轻量级虚拟机，在虚拟机里跑 Linux 内核和 Docker 引擎。这条路线比较“重”，但兼容性也最完整。
另一条是 WSL2 后端，也是新版 Docker Desktop 默认推荐的方案。WSL2 本质上是微软对 Windows 内核做的一个“Linux 兼容层”，它不是虚拟机，但底层又实实在在用到了 Hyper-V 的虚拟化技术。Docker Desktop 检测到 WSL2 可用之后，就把引擎挂到 WSL2 里运行，启动速度更快，内存占用也更小。
重点来了：不管走哪条路线，Docker Desktop 都需要 Windows 的虚拟化功能（Hyper-V 平台 / 虚拟机监控程序）处于可用状态。所以哪怕你 BIOS 开了 VT-x，Docker 还是会报虚拟化错误，就是因为 Windows 层面的“虚拟机监控程序”没有启动，或者 WSL 没有正确接入。这也是为什么很多时候 BIOS 开关并不能解决全部问题。
2. 动手前的体检：快速定位卡在哪一层
2.1 五步自查清单
在动手改配置之前，我先列一份排查清单。按这个顺序检查，能少走很多弯路：
- 确认 CPU 虚拟化是否已在 BIOS 中开启。重启进 BIOS，找 Intel Virtualization Technology（Intel 平台）或 SVM Mode（AMD 平台），设为 Enabled。
- 确认 Windows 版本支持 Hyper-V 或 WSL2。Windows 10 专业版/企业版/教育版、Windows 11 全系都支持；Windows 10 家庭版不支持完整 Hyper-V，但支持 WSL2，而 Docker Desktop 走 WSL2 后端也没问题。
- 确认 Windows 功能里“虚拟机平台”“适用于 Linux 的 Windows 子系统”“Hyper-V”这些组件是否启用。
- 确认 WSL 已安装且默认版本是 2 代内核。
- 确认没有第三方安全软件、旧版虚拟机工具（比如老版本的 VirtualBox）在抢占虚拟化资源。
不要一上来就重装 Docker Desktop，那不是根因。先跑一遍体检，确定问题在哪一层再动手。
2.2 常用诊断命令与输出解读
Windows 下诊断虚拟化状态，我喜欢用下面几个命令，都是系统自带的，不需要额外安装工具。
第一个是systeminfo，在 CMD 或 PowerShell 里运行。输出结果底部有一块叫“Hyper-V 要求”，如果显示“已检测到虚拟机监控程序。将不显示 Hyper-V 所需的功能。”，说明 Hyper-V 已经在运行，这是好事；如果显示“固件中已启用虚拟化”，但下面又说“未检测到虚拟机监控程序”，说明硬件开了但系统层的 Hyper-V 没启动，问题出在 Windows 功能上。
第二个是wsl --status和wsl --version，用来查看 WSL 的状态。正常情况下会显示默认版本是 2，内核版本号也比较新。如果提示“正在进行第一次安装”，或者“WSL 1 已安装”，那就需要重点处理 WSL 相关配置。
第三个是bcdedit /enum | findstr hypervisor，在管理员权限下运行。如果输出里面有hypervisorlaunchtype Auto，说明系统开机时引导了虚拟机监控程序。如果是Off，说明 Hyper-V 被禁用，需要执行bcdedit /set hypervisorlaunchtype auto再重启。
这三个命令分别对应硬件层、WSL 层、系统引导层，组合起来用，基本能定位八成以上的问题。
3. 全流程实操：从 BIOS 到 Docker Desktop 启动
3.1 第一步：确认并开启硬件虚拟化
先处理最底层的问题。重启电脑，按品牌对应的按键进 BIOS（常见的有 F2、Del、F10），不同机器路径不一样，但关键词基本一致。Intel 平台找 “Virtualization Technology”、“VT-x” 或 “Intel Virtualization”，AMD 平台找 “SVM Mode”。设置成 Enabled 之后保存退出。
这里有个坑：部分轻薄本或商务机的 BIOS 是精简版，找不到虚拟化选项，但机器本身是支持 VT-x 的。这种情况下，虚拟化开关可能被锁在固件里，由出厂设置决定，用户无法修改。判断方法其实很简单，去任务管理器 -> 性能 -> CPU，看右下角“虚拟化”一栏。如果显示“已启用”，说明硬件没问题；如果显示“已禁用”且 BIOS 里又找不到开关，那大概率是机器固件锁死了虚拟化，这种情况无法靠软件层面解决。
另外提醒一句：如果你是 AMD 平台，有些主板默认把 SVM 隐藏了，需要先把 BIOS 切换成“高级模式”或者“专家模式”才能看到，别在简易模式里翻半天找不到就以为不支持。
3.2 第二步：启用 Windows 可选功能
硬件层确认没问题之后，接下来是 Windows 功能层。这里推荐优先打开“虚拟机平台”和“适用于 Linux 的 Windows 子系统”这两项，尤其是走 WSL2 路线的用户。如果你用的是专业版，也可以一并勾选“Hyper-V”。
用图形界面操作的话，路径是：控制面板 -> 程序 -> 启用或关闭 Windows 功能，会弹出一个功能列表，找到下面这几项：
- 虚拟机平台（Virtual Machine Platform）
- 适用于 Linux 的 Windows 子系统（Windows Subsystem for Linux）
- Hyper-V（可选，含 Hyper-V 管理工具和 Hyper-V 平台两个子项）
勾选后点确定，系统会提示重启。
用命令行更直接，在管理员权限的 PowerShell 里执行：
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart dism.exe /online /enable-feature /featurename:Microsoft-Hyper-V-All /all /norestart这三条命令分别对应 WSL、虚拟机平台、Hyper-V，执行完统一重启一次。
这里特别想说明一下“虚拟机平台”和 Hyper-V 的关系。很多人以为只有装 Hyper-V 才能跑 Docker，其实不对。WSL2 依赖的是“虚拟机平台”这个更底层的功能，Hyper-V 只是它的一个应用外壳。你只开 WSL2 + 虚拟机平台就够了，不装完整的 Hyper-V 反而能避免和某些第三方模拟器的冲突。如果你同时装了雷电模拟器、夜神模拟器这类依赖自带虚拟化技术的软件，它们和 Hyper-V 偶尔会打架，导致 Docker 启动失败。所以我的建议是：非必要不装 Hyper-V 全部组件，够用就行。
3.3 第三步：安装和配置 WSL2
Windows 功能启用之后，还需要确认 WSL 本体是否安装、版本是否正常。从 Windows 10 2004 版本开始，微软把 WSL 做成了独立组件，可以在管理员 PowerShell 里用一条命令安装：
wsl --install这条命令会默认安装 WSL2 内核，并顺带装一个 Ubuntu 发行版。安装完成后按提示重启电脑，然后执行：
wsl --set-default-version 2把默认 WSL 版本切换成 2 代。这一步非常关键，Docker Desktop 的 WSL2 后端要求 WSL 必须是 2 代，如果停在 1 代，Docker 会报虚拟化错误或者直接找不到后端。
有些机器之前装过 WSL1，升级到 WSL2 之后可能还需要手动更新内核。直接跑：
wsl --update它会从微软服务器拉取最新内核并完成安装。更新完执行wsl --status确认状态，输出里应该能看到“默认版本: 2”的字样。
这一个环节我遇到最多的坑是：wsl --install执行到一半报错，提示需要启用虚拟机平台。其实是因为第 3.2 步的 Windows 功能没有重启生效，或者安装内核时被安全软件拦截了。遇到这种情况，先确认 Windows 功能已启用并重启，再以管理员身份重新跑一次wsl --install。
如果wsl --install一直失败，也可以去微软官网手动下载 WSL2 内核更新包 wsl_update_x64.msi，装完再执行wsl --set-default-version 2。这个方案在 Win10 老版本上很实用。
3.4 第四步：切换 Docker Desktop 引擎并启动
Docker Desktop 安装完成后的第一个启动，建议先打开它的 Settings 看一眼。在 General 选项卡里，找到 “Use the WSL 2 based engine” 这个选项，确保它是勾选状态。新版 Docker Desktop 默认就是勾选的，但如果你之前手动改成过 Hyper-V 模式，这里就需要切回来，或者干脆关掉重新启动一次。
然后切到 Resources -> WSL Integration 选项卡，确认你准备用的发行版（比如 Ubuntu）在开启列表里。这一步的意义是，Docker 引擎跑在 WSL2 里，而你的终端操作也想通过 WSL 访问到 Docker 命令，两者必须在同一个 WSL 环境里。
配置完成后，点右下角的 “Apply & Restart”。正常情况下，Docker Desktop 状态栏的鲸鱼图标会从动画状态变成稳定的运行状态，然后打开终端执行docker version和docker ps验证。
如果你走到这一步还启动失败，并且报错带有 0x80370102，那就是虚拟机监控程序没有真正拉起来。回到管理员 CMD，执行：
bcdedit /set hypervisorlaunchtype auto然后重启电脑。这条命令是让 Windows 在系统引导阶段就直接加载 Hyper-V 虚拟机监控程序，不管 Docker 是否开启，系统都会保留这个虚拟化层。重启后再启动 Docker Desktop，基本就能过了。
4. 常见问题与排查技巧实录
4.1 排错速查表
把这些年我在实际排障中遇到的问题整理成一张表，方便大家对照着查：
| 报错现象 | 根本原因 | 处理方式 |
|---|---|---|
| Docker Desktop failed to start because virtualisation support wasn‘t detected | BIOS 虚拟化未开启或无可用的虚拟化平台 | 进 BIOS 开启 VT-x/SVM 或确认 Windows 功能已启用 |
| 启动报 0x80370102，提示虚拟机监控程序未运行 | Windows 功能未启用或 hypervisorlaunchtype 被设为 Off | 启用虚拟机平台/Hyper-V，执行 bcdedit 命令后重启 |
| WSL 相关报错，提示找不到 WSL 2 内核 | WSL 内核未更新或默认版本是 1 | 执行 wsl --update、wsl --set-default-version 2 |
| 虚拟机平台功能安装失败 | 系统更新补丁缺失或安全软件拦截 | 安装最新 Windows 更新，关闭安全软件后重试 |
| Docker Desktop 启动后反复重启 | WSL Integration 配置异常或资源不足 | 检查 Docker Desktop 的 WSL 集成选项，调整内存配额 |
| 同时使用第三方模拟器后 Docker 无法启动 | 第三方模拟器占用虚拟化资源，与 Hyper-V 冲突 | 关闭模拟器的嵌套虚拟化，或在 Docker 设置里切换 WSL2 模式 |
这张表不是万能药，但覆盖了 90% 的常见场景。如果表里没有你的问题，大概率要从系统层面看具体日志了，Windows 的事件查看器里可以找到 Docker 服务的错误记录，路径是“应用程序和服务日志”下的 Docker 分类。
4.2 反复踩过的几个坑
第一个坑：VBS（基于虚拟化的安全）干扰。Windows 11 默认开启内存完整性和核心隔离，这个功能本身也是基于 Hyper-V 的。有时候 VBS 和 Docker Desktop 的虚拟化检测会互相打架，导致明明所有组件都正常，Docker 还是起不来。如果确认所有配置没问题，去“Windows 安全中心 -> 设备安全性 -> 内核隔离”里，关掉“内存完整性”，重启后再试。
第二个坑：老电脑不支持 SLAT（二级地址转换）。Windows 的 Hyper-V 要求 CPU 必须支持 SLAT，否则无法运行。老 CPU 虽然能开 VT-x，但不一定有 SLAT。可以用工具检测，如果没有 SLAT，那就只能放弃 Hyper-V 后端，改用 Docker Toolbox 那套基于 VirtualBox 的方案，或者干脆换一台新设备。这个情况比较少见，但遇到会非常挫败，提前知晓能少走弯路。
第三个坑：杀毒软件和系统优化软件强制关闭了 Windows 功能。有一些“一键优化”工具会把虚拟机平台、Xbox 服务这类组件当成“无用项”精简掉。最让人头疼的是，功能列表里看着是勾选的，但底层组件文件已经被删了。遇到这种，只能重新勾选并重启，再不行就检查系统文件：
sfc /scannow dism /online /cleanup-image /restorehealth这两个命令能修复部分系统组件损坏的问题，修复完再重启验证。
最后再分享一个我自己的操作习惯
我每次在 Windows 上装完系统，第一件事就是顺手把 WSL 和虚拟化相关的功能全部打开并更新到最新，而不是等 Docker 报错了再回去补。流程只有三条命令：wsl --install、wsl --update、wsl --set-default-version 2，再配合systeminfo检查一下。这样一套下来，后面装 Docker Desktop 基本是一路绿到底。
如果你这次折腾了很久都没解决，不妨把电脑重启一遍再按上面的顺序重新检查。很多时候不是某个环节太难，而是开了好几个开关但少了一次重启，系统一直没把最新的配置加载进来。仔细走一遍，Docker 跑起来之后，后面部署项目、拉镜像这些操作就顺了。
 详解：用谓词函数断言“任一节点满足条件”)
