刚在 Windows 上装完 Docker Desktop 的人，大概率都有过这么一段经历：图标双击，小鲸鱼转了一会儿圈，任务栏图标变灰，鼠标挪上去一看——Windows 系统里弹出“Virtualization support not detected”。没头没尾，就这一句，Settings 里也没更多细节。第一次遇到的人十有八九会怀疑自己是不是碰上了什么奇怪问题。其实这条报错没那么神秘，它是 Docker Desktop 在本机做虚拟化自检时打回来的一记重拳。这篇文章就把这事一次说透：从报错背后的检测链路、BIOS 开关、Windows 功能、WSL2 内核，到那些文档里不会写的隐性坑，一步步带你把 Docker 真正跑起来。适合所有在 Windows 上想用 Docker Desktop 却启动失败的人。
1. “Virtualization support not detected”到底在检查什么
1.1 报错的常见画面与触发人群
先说清楚这条报错最容易出现在哪些人身上。我处理过的案例里，最常见的是三类：第一类是刚装好系统就想跑 Docker 的人，BIOS 里的虚拟化开关没开；第二类是公司统一分发的笔记本，固件设置被策略锁死，虚拟化选项显示正常但实际没生效；第三类是在虚拟机上套娃装 Windows 的人，宿主没把虚拟化透传进来，系统里怎么看都是好的，可 Docker 就是报这个错。当然，还有一类比较隐蔽：本身已经能正常跑 WSL2，但自己升级过一次 Windows 大版本之后，Docker Desktop 忽然就起不来了。
这类报错最迷惑的地方在于，Docker Desktop 不会告诉你它检查到了哪一步。它只是在启动时跑完一连串自检，然后把第一关不过的结果丢给你。所以排查的思路不是盯着这句话猜，而是沿着它的检测链路从上往下捋。下面先把这条链路的每一环拆开。
1.2 Windows 上的 Docker 为什么离不开虚拟化
许多人第一次接触 Docker，脑子里默认它是像普通软件一样装到系统里就跑的。但在 Windows 上，Docker 的容器之所以能跑起来，是因为背后有一个 Linux 内核在虚拟机里负责执行。你可以这样理解：容器镜像里装的都是各种 Linux 程序，Windows 内核没法直接调度它们，必须有个轻量虚拟机兜底，在里面起一个 Linux 内核，再让 Docker 引擎跟这个内核打交道。
Docker Desktop 在 Windows 上有两套后端可以选择：一套走 Hyper-V，一套走 WSL2。默认建议用 WSL2，因为更省资源、启动更快。但不管走哪套，底层都需要 CPU 虚拟化扩展的支持。如果是 Intel 平台，就要用到 VT-x；如果是 AMD 平台，就要用到 AMD-V / SVM。没有这一层，任何虚拟化方案都无从谈起。所以“Virtualization support not detected”这句话，翻译过来就是：Docker Desktop 在系统里没找到 CPU 虚拟化这条供电线。
1.3 检测链路拆解：为什么“已启用”还不顺
现在关键问题来了：很多人打开任务管理器，“性能”页里 CPU 那一栏明明写着“虚拟化：已启用”，可 Docker 照样报这个错。这里就需要理解 Docker Desktop 的检测并不是只看 CPU 支不支持，而是一条完整的链路：CPU 和固件（BIOS/UEFI）→ Windows 的虚拟化组件（虚拟机平台或 Hyper-V）→ 管理程序的启动状态 → WSL2 内核是否可用 → Docker 引擎启动。任何一个环节断了，报错都可能是同一条。
任务管理器显示“虚拟化：已启用”，只能代表第一环过了。后面 Windows 功能没装、管理程序没加载、WSL2 内核没更新，照样能给出同一个错误提示。这也是很多人反复折腾 BIOS 却始终无效的原因——你浪费了半小时改设置，其实问题在后半程。下面各章就是按这条链路从前往后逐个排查。
2. 第一道门：BIOS 里的 VT-x / AMD-V 开关
2.1 开关位置与命名：不同平台怎么找
先说说最基础但又最容易被忽略的：BIOS 里的虚拟化开关。Intel 平台一般叫 Intel Virtualization Technology 或 VT-x，AMD 平台叫 SVM Mode 或 Secure Virtual Machine，还有个别主板叫 AMD Virtualization。名字不一样，但作用一样：让 CPU 的虚拟化指令可以真正被操作系统使用。默认情况下，很多台式机主板开了虚拟化，但相当一部分笔记本却是关着的，尤其是品牌机的出厂默认设置可能为了省电和兼容性把这个选项藏起来。
位置方面，台式机主板通常在 Advanced 或 Overclocking 菜单下的 CPU Configuration 里；笔记本则比较随缘，有些在 Security 子菜单，有些在 System Configuration，有些在 Virtualization 或 Advanced 里。如果 BIOS 界面是中文的，找“虚拟化”三个字；英文则搜索 Virtualization / VT / SVM 都可以。改完之后 F10 保存退出，让系统重启。
这里有个小经验：找到选项后，别在 BIOS 里看到 Disabled 就只改它。有些机器还有单独一档 VT-d 或者 Intel Trusted Execution Technology，虽然 Docker 用不到，但某些 Windows 安全功能会依赖它们，顺手一并打开反而能少很多后续麻烦。
2.2 不是开了就行：用任务管理器和 systeminfo 验证
改完 BIOS 后，第一步验证就是重启后打开任务管理器，看 CPU 部分的“虚拟化”行是否显示“已启用”。如果已经是，说明固件层通过了。但任务管理器只回答了第一层问题，为了看得更细，建议开一个管理员命令行窗口，跑一条命令：
systeminfo | findstr /i "hyper-v"输出内容里如果看到“固件中已启用虚拟化: 是”，并且“虚拟机监视器扩展”和“二级地址转换”都是“是”，那说明 CPU 和固件层面完全正常。如果显示“否”，那 BIOS 开关大概率没生效，回上一步继续检查。如果输出直接把整个 Hyper-V 要求段落省略，并提示“已检测到虚拟机监控程序”，那就说明系统现在已经在某个虚拟机监控程序里运行，这往往是嵌套虚拟化的场景，对应第 5 章专门讨论。
任务管理器显示“已启用”时，systeminfo 里一般也不会差。但有些精简版系统或安全策略会改写检测结果，所以我更信任 systeminfo 的输出。我亲眼见过任务管理器显示“已启用”、systeminfo 显示“否”的情况，原因出在某些固件在 Windows 引导后才启动虚拟化特性，属于极少数特例。
2.3 快速启动导致的“假阴性”
这是一个实操中很容易中招的点：BIOS 里明明已开启，任务管理器却显示“已禁用”。常见原因之一是 Windows 的快速启动。快速启动会让系统关机时进入一种混合休眠状态，下次开机不是真正从 BIOS 重新初始化，硬件状态可能还停留在关机的快照里。这时候你改了 BIOS，关机再开机，系统根本不会重新扫描固件设置。
正确做法是彻底断电重启：在 Windows 里运行shutdown /s /f /t 0，或者按住 Shift 点“重启”，让系统绕过快速启动完成一次完整重启。笔记本如果方便，关机后拔掉电源再开机是最稳妥的。改完 BIOS 后连续遇到假阴性，我一般会关机、断电、等几秒再开，一步到位。
3. 给 Windows 把虚拟化跑道铺好
3.1 按后端选功能：WSL2 需要什么、Hyper-V 需要什么
Docker Desktop 的两种后端，对应的 Windows 功能不完全一样。如果默认使用 WSL2 后端，需要开启两个功能：“适用于 Linux 的 Windows 子系统”（Windows Subsystem for Linux，WSL）和“虚拟机平台”（Virtual Machine Platform）。WSL2 的架构本质是把 Linux 内核放到一台轻量级虚拟机里跑，而“虚拟机平台”正是提供这层虚拟化能力的底座。很多人只启用了 WSL 没启用虚拟机平台，wsl 能安装但跑不了 version 2，Docker 跟着报错。
如果选择 Hyper-V 后端，则需要开启 Hyper-V 功能，以及“容器”（Containers）功能。这里有个容易混淆的点：Hyper-V 后端需要的是独立的 Hyper-V 管理程序栈，而 WSL2 后端恰恰不要求完整的 Hyper-V 功能，只要虚拟机平台就好。对大多数普通用户，尤其是笔记本用户，WSL2 后端更轻、体验更好，建议优先走这条路。下表汇总了两套后端所需的功能。
| 功能 | WSL2 后端 | Hyper-V 后端 |
|---|---|---|
| 适用于 Linux 的 Windows 子系统 | 必须 | 不需要 |
| 虚拟机平台 | 必须 | 不需要 |
| Hyper-V | 不需要 | 必须 |
| 容器 | 不需要 | 必须 |
注意：Windows 家庭版不提供完整 Hyper-V 功能，所以家庭版用户只能依靠 WSL2 后端。这个限制不影响装 Docker Desktop，只是别在选功能时硬找 Hyper-V 的开关。我遇到过用户在网上照着教程想开 Hyper-V 却找不到，导致 Docker 一直起不来，最后才发现教程假设的是专业版。
3.2 三步启用：GUI、DISM、状态确认
第一步是用管理员权限打开 PowerShell，执行下面两行（按需组合）：
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart第一行启用 WSL 组件，第二行启用虚拟机平台。两个都加/norestart，避免系统半路重启打断操作。如果打算走 Hyper-V 后端，需要额外开 Hyper-V 和容器：
dism.exe /online /enable-feature /featurename:Microsoft-Hyper-V-All /all dism.exe /online /enable-feature /featurename:Containers /all这两条执行完一般会要求重启，执行时把其他程序先保存好。
第二步：重启机器。这一步别省，也尽量别跳过。Windows 的这些可选功能不是装完就能用，要等组件真正写入引导配置并完成初始化。第三步是确认状态：
Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux, VirtualMachinePlatform输出里 State 为 Enabled 就表示成功。如果输出报找不到功能名，说明系统版本太老或者系统是特殊精简版，此时需要走下文的旧版安装路线。
3.3 hypervisorlaunchtype 和家庭版限制
检查完功能栏，还有一处容易被忽略：管理程序的启动状态。Windows 里的 Hyper-V 管理程序并不是启用功能后就立刻常驻，它由一条引导参数控制。用管理员命令行执行：
bcdedit /enum {current} | findstr hypervisorlaunchtype正常情况下输出是hypervisorlaunchtype Auto。如果在前面装过 Hyper-V 或手动改过引导参数，这条值可能变成 Off，那么功能开着也没用，Docker 照样探测不到虚拟化。修复命令：
bcdedit /set hypervisorlaunchtype auto同样要管理员权限，改完重启。这里必须提醒：把 hypervisorlaunchtype 设成 Auto 意味着 Windows 每次启动都会加载它的虚拟化层，这一特性会抢占 CPU 虚拟化扩展，导致某些第三方虚拟机无法直接使用硬件加速。如果你同时还在用其他虚拟化软件，先想清楚到底留谁。
4. WSL2 内核和版本：坑最深、最隐蔽
4.1 先看 WSL 状态和默认版本
到了这一环节，很多人会疑惑：功能都开了，BIOS 也没问题，怎么 Docker 还是那句话。大概率是 WSL2 的内核或版本没跟上。先用管理员执行：
wsl --status输出里如果能看到“默认版本: 2”，基本正常；如果显示“默认版本: 1”，或者明明装了 Linux 发行版却显示 Version 1，那就是典型的内核/版本不匹配。运行下面命令把默认版本改成 2：
wsl --set-default-version 2执行的同时，官方内核文件会自动下载安装。如果网络状况不好或者这一步静默失败，wsl 状态就一直停在 version 1。新版 Windows 里还可以用wsl --version查看 WSL 自身版本，判断是不是旧内核。老内核包会导致 Docker 报类似“需要更新的 WSL 内核”的提示，但有时候也会泛化成虚拟化未检测到，所以这块值得优先确认。
4.2 老系统补内核：手动安装包
如果你的 Windows 版本比较早，比如 Windows 10 里 2004 之前的版本，或者 1903/1909 那种老版本，wsl --set-default-version 2很可能直接提示需要先安装 WSL2 内核。Windows 10 2004 之前不内置 WSL2 的完整支持，但只要 CPU 支持虚拟化，依然可以通过手动装内核包的方式跑起来。这时候要从官方渠道下载 WSL2 Linux 内核更新包（x64 或 arm64），按提示安装，再切默认版本。
另一个常见场景是公司的域控电脑或者教育版本，某些组件被系统策略锁住，wsl --install可能根本没反应。手动安装内核包反而能绕过部分限制。装完后重新执行wsl --status，确认默认版本变成 2，再把 Docker Desktop 重新启动一次。
补充一句：Docker Desktop 本身对系统版本也有要求，太老的操作系统即便能装，也建议先看官方系统要求。如果版本实在陈旧（比如 Windows 10 1903 之前），优先考虑先升级再折腾，很多时候升级系统比绕各种坑更省时间。毕竟你最终要的是稳定地跑容器，不是怀旧。
4.3 wsl --update 失败时的备用路线
新版 Windows 的 WSL 已经从内核组件变成了应用商店里的独立应用。wsl --update要从商店或系统更新服务器拉包，一旦网络代理、系统策略或应用商店有问题，更新就很容易失败。遇到这种情况，先看一眼命令窗口有没有明确报错。没有明确错误但一直卡住的话，可以考虑卸载商店版 WSL 再重新装：在“应用”里卸载 Windows Subsystem for Linux 相关组件，然后重新执行wsl --install --no-distribution，只装 WSL 本体不装发行版。装好后再wsl --set-default-version 2。
如果网络环境连商店也连不上，那就回到手动安装内核包这条备用路线。内核包是独立的 MSI 安装程序，装完即使是没有商店的特殊版本也能让 WSL2 跑起来。实测这套流程在不少受控环境里反而最稳定。建议手动安装后顺手确认版本，别装完就以为万事大吉。
5. 实测中那些“看不见”的干扰源
5.1 已装过 VirtualBox / VMware 怎么办
这是很多人都遇到的真实场景：电脑上装了 VMware Workstation 或 VirtualBox，平时要跑其他虚拟机，现在又装 Docker Desktop，结果两边都起不来。核心矛盾是 CPU 虚拟化扩展被 Windows 的 Hyper-V 管理程序接管后，第三方虚拟化软件无法再直接拿到硬件加速。两种软件现在的新版本都支持通过 Windows Hypervisor Platform（WHP）作为中介来兼容，但兼容性并不完美。反过来，如果你先装了第三方虚拟机，Docker Desktop 自检时也可能探不到虚拟化。
处理思路很清晰：核心用途是什么就保谁。主要用 Docker，就卸载或停用第三方虚拟机，或者将其设置为通过 WHP 运行；主要用第三方虚拟机，就暂时不要开 Hyper-V 和虚拟机平台，Docker Desktop 走不了 WSL2 就是必然。还有一个折中方案：保留第三方虚拟机软件，但确保其版本支持并启用了 Hyper-V 兼容模式，这样两边能凑合共存。但说实话，生产环境里我一般建议物理机只保留一个虚拟化栈，省得来回调试互相干扰。
5.2 安全软件、内存完整性与嵌套虚拟化
另一类很隐蔽的干扰来自安全层。Windows 安全中心的“内核隔离”功能，在系统上使用了基于虚拟化的安全机制。在多数环境下它跟 Docker 可以共存，但在某些设备驱动、安全软件的组合下，会干扰虚拟化扩展的可见性。另外，部分第三方安全软件（尤其是带进程防护和网络防护的）会对 wsl.exe、docker 进程做 hook，导致 WSL 内核加载失败。排查时如果以上全部正常还没解决，可以临时关闭相关安全防护或内核隔离，再试一次 Docker。这里特别强调：只是排查阶段临时关闭，确认完记得恢复。
还有一种场景经常被忽略：你的 Windows 本身就是装在一台虚拟机里的。不管宿主用的是哪套虚拟化平台，都必须把虚拟化指令透传给客户机。常见做法是开启嵌套虚拟化选项，让客户机看到 CPU 的 VT-x/AMD-V。如果没开，客户机里任务管理器都会显示虚拟化已禁用，但用户根本没意识到自己其实在虚拟机里，还以为是物理机的 BIOS 问题。遇到这种情况，与其折腾半天，不如先确认自己的系统是不是跑在虚拟化环境里。
5.3 一套有序的最终验证流程
以上每一步做完都可能需要重启。与其反复试错，不如按一套固定顺序走，每次做完一步重启一次，确认结果对了再往下。我习惯的顺序是：第一，任务管理器看虚拟化是否已启用；第二，用 systeminfo 确认固件虚拟化是真开启；第三，Get-WindowsOptionalFeature 确认 WSL 和虚拟机平台已启用；第四，看 bcdedit 里的 hypervisorlaunchtype 是 Auto；第五，wsl --status 确认默认版本是 2；最后，启动 Docker Desktop，用两条命令做最终验证：
docker versiondocker run hello-worlddocker version能看到 Client 和 Server 两段，如果只有 Client 没有 Server，说明 Docker 引擎没起来。docker run hello-world能完整跑通，说明整个链路已经通了。走到这里还没解决，那基本可以确定是个性化硬件或系统定制的问题，建议带上 systeminfo、wsl --status、bcdedit 的输出去找专业人士判断。
最后说点个人经验。我处理得多了，越来越觉得这类报错不值得恐惧，它只是把一串依赖环节的检测结果压缩成了一句含糊提示。很多人在 BIOS 里反复折腾，白白消耗耐心，其实问题往往在后半段：功能没开全、WSL2 内核没更新、或者虚拟化环境本身嵌套。有一次帮 A 同学排查，折腾了两天，最后发现就是wsl --update后忘了把默认版本切到 2。这类小坑，排查手册上根本不会提前写。希望这篇能帮你少走这几天的弯路。
