刚从同事的电脑前起身它屏幕上还挂着那条让人血压升高的提示Docker Desktop failed to start because virtualization support wasnt detected。我太熟悉这行英文了。这几年不管是帮朋友装开发环境还是处理公司新入职同事的电脑只要和 Docker 沾边大概率都能碰见这个 “Virtualization support not detected” 的报错。说白了Docker Desktop 在 Windows 上并不是直接跑 Linux 容器的它需要靠 Windows 虚拟化层托起一个轻量的 Linux 虚拟机再在虚拟机里运行 Docker 引擎。而虚拟化层要工作BIOS 里的 CPU 虚拟化开关、Windows 的虚拟化组件、WSL2 的 Linux 内核、Docker Desktop 的后端设置这四个环节必须全部打通。这条链路里任何一环断了弹窗就会甩出这一句 “Virtualization support not detected”。这篇内容我按自己处理过的几十台机器的经验把从报错原理到每一层修复的具体步骤都整理了一遍。不管你是刚下载完 Docker Desktop 的 Windows 新手还是已经被这个报错折磨了一下午的老开发按顺序走一遍多半能解决。1. 这个报错到底在报什么Docker Desktop 的虚拟化依赖链路1.1 报错信息出现的几个典型场景很多人以为这个报错只在安装 Docker Desktop 后第一次启动时出现实际上我遇到的情况要复杂一些。最常见的当然是黑框一闪然后弹窗提示 “Virtualization support not detectedDocker Desktop failed to start because virtualization support wasnt detected”。但还有几个高频时机容易被忽视第一种是 Docker Desktop 大版本升级之后比如从 4.19 升到 4.27升级完再点 Launch Docker Desktop突然就报这个错。这通常不是 Docker 坏了而是升级过程中重新检测了系统虚拟化状态原本就没配完整的机器这时候原形毕露。第二种是 Windows 系统更新之后尤其是七零八落的大版本更新比如 Windows 10 升 Windows 11或者 Windows 11 的 23H2 到 24H2部分系统的虚拟化组件会被重置或关掉Docker 就跟着起不来了。第三种是自己折腾过 Hyper-V 或 WSL 后出现的可能你之前用 wsl --set-default-version 1 切回过旧版 WSL或者手动关过 hypervisorlaunchtypeDocker Desktop 启动时检测到虚拟化链路不对也会甩出同一句话。这三种场景原因各不相同但弹窗文案一模一样这就是为什么网上搜到的各种“妙招”时灵时不灵——因为大家断掉的开关根本不是同一个。1.2 从“Virtualization support”看 Docker 在 Windows 的运行原理要彻底搞懂这个报错得先明白 Docker Desktop 在 Windows 上的运行机制。它不像 Linux 里那样直接把 Docker 引擎跑在宿主机上而是借助一个轻量级虚拟机来跑 Linux 容器。这个虚拟机有两条路线一条是 WSL2 后端Docker Desktop 4.x 默认推荐另一条是老牌 Hyper-V 后端。无论走哪条路线底层都要用到 Windows 的虚拟机监控程序Hypervisor而 Hypervisor 又必须依赖 CPU 的硬件虚拟化扩展Intel 平台叫 VT-xAMD 平台叫 SVM。这套依赖从最底层的硬件 BIOS 设置到 Windows 功能开关再到 WSL2 内核最后到 Docker Desktop 的设置是一条完整的链。我用一个生活化的类比Docker 是坐电梯的乘客虚拟化层是电梯BIOS 里的 VT-x 开关相当于电梯电闸Windows 的虚拟化组件相当于电梯按钮。电闸没合上、按钮坏了、或者电梯被别的住户占用了乘客都会被困在楼下。“Virtualization support not detected” 是电梯口贴的那张告示你不查电路光在这儿撬电梯门当然没用。1.3 三个必须同时满足的开关我习惯把虚拟化支持按层级拆成三个独立开关第一层是硬件开关在 BIOS/UEFI 设置里Intel 平台叫 “Intel Virtualization Technology” 或 “VT-x”AMD 平台叫 “SVM Mode”。这一层没开系统中所有虚拟化相关的软件都会失效。第二层是系统开关在 Windows 的“启用或关闭 Windows 功能”里相关的组件包括 Hyper-V、虚拟机平台Virtual Machine Platform、Windows 虚拟机监控程序平台还有适用于 Linux 的 Windows 子系统。这一层没打开Docker Desktop 检测不到可用的虚拟化接口。第三层是应用开关就是 Docker Desktop 设置里是否勾选了 “Use the WSL 2 based engine”。有些机器系统层完全没问题但 Docker Desktop 启动时还走的是老式 Hyper-V 后端或者设置没保存成功同样会报错。这三个开关是串联的任何一个断开Docker Desktop 报的都是同一个错误。后面所有的排查步骤本质上就是围绕这三个开关一个一个确认、一层一层修复。2. 动手前的三分钟体检先确认虚拟化到底开没开2.1 任务管理器的“性能”标签页拿到一台报错的机器我不会先急着改配置而是先花三分钟做个快速体检。第一个动作是打开任务管理器切到“性能”标签页选左侧的“CPU”右下角会有一行“虚拟化”的状态。如果显示“已启用”说明 BIOS 这一层显卡没问题如果显示“已禁用”那不用想了问题基本就锁定在 BIOS/UEFI 层。这里有个细节需要注意不同 Windows 版本显示的文字不太一样。Windows 11 的某些新版本在虚拟化那行会写成“虚拟化: 已启用Hyper-V 在此计算机上运行”这说明 Hypervisor 本身已经启动状态比普通“已启用”更进一步。如果显示的是“已禁用”别花时间折腾 Windows 功能和 Docker 设置了直接重启进 BIOS。另外任务管理器里如果压根看不到“虚拟化”这一项通常是 CPU 太老或者主板 BIOS 版本太旧不支持相关指令集。这种情况就算 BIOS 设置里有开关也建议先更新一下主板 BIOS 再继续。2.2 命令行体检systeminfo 与 bcdedit任务管理器看的是 CPU 层面的虚拟化但 Windows 能不能真正使用它还要看系统层面的状态。用管理员身份打开 PowerShell右键开始菜单选“终端(管理员)”输入 systeminfo拉到输出末尾会看到一段以“Hyper-V 要求”开头的内容里面有四行虚拟机监控程序模式扩展固件中已启用虚拟化二级地址转换数据执行保护理想情况下四行都应该是“是”。如果第一行“虚拟机监控程序模式扩展”显示“否”说明 BIOS 里的 VT-x/SVM 没开。如果第二行“固件中已启用虚拟化”显示“否”同样是 BIOS 问题。但如果是第三行“二级地址转换”或第四行“数据执行保护”显示“否”那麻烦一点通常是 CPU 太老不支持 SLAT 或 DEP这种情况即便虚拟化开着Hyper-V 和 WSL2 也不好使。还有一条命令我也经常用bcdedit /enum {current}找到名为 hypervisorlaunchtype 的选项。它显示 Auto表示 Hypervisor 开机自动启动显示 Off表示被手动关掉了。如果这里被改过Docker、WSL2、Hyper-V 全都会受影响。需要恢复时在管理员 PowerShell 里执行 bcdedit /set hypervisorlaunchtype auto然后重启。2.3 检查 WSL 的状态Docker Desktop 4.x 默认依赖 WSL2所以 WSL 本身的状态是否健康也很关键。管理员 PowerShell 里运行 wsl --status它会显示默认版本、内核版本等信息。再运行 wsl --version看 WSL 自身版本号太旧的话后面可能出问题。我遇到过很多次wsl --status 输出里写着“默认版本: 1”而 Docker Desktop 需要的是版本 2。或者输出直接提示 “WSL 未安装”但系统里明明有“适用于 Linux 的 Windows 子系统”这个功能。这些情况都会导致 Docker Desktop 启动时报虚拟化支持未检测到。这里有个容易误解的地方很多人以为装完 Docker Desktop 就万事俱备了其实 Docker Desktop 安装包只负责把主程序拷进去WSL2 的 Linux 内核更新包是独立的系统得单独装或者靠 wsl --update 拉取。我见过太多人卡在这一步总是去重装 Docker结果重装十遍也没用问题根本不在 Docker 身上。3. 从上到下逐层修复BIOS、Windows 功能、WSL2 内核3.1 第一步进 BIOS/UEFI 打开 CPU 虚拟化如果体检发现任务管理器或 systeminfo 显示 BIOS 层没开虚拟化就得重启进 BIOS 了。各品牌主板进 BIOS 的快捷键不一样台式机主板大多是 DEL笔记本常见的是 F2也有些是 F10、F12。开机时连续按对应键就行不建议一个个试直接看你主板或笔记本的品牌搜索“品牌名 进BIOS键”更快。进入 BIOS 后界面风格看厂商。Intel 平台找 “Intel Virtualization Technology”有些新主板写的是 “VT-x”还有的藏在 “Advanced” 或 “Processor Configuration” 子菜单里。AMD 平台找 “SVM Mode” 或 “Secure Virtual Machine Mode”。把状态从 Disabled 改成 Enabled保存退出通常 F10。这里提醒一句改完 BIOS 里虚拟化选项后如果系统还是显示未启用别急着怀疑改错了。部分主板尤其是笔记本改了 BIOS 后需要彻底断电一次才生效。办法是关机、拔掉电源线、如果是笔记本再抠出电池现在很多内置电池那就长按电源键十几秒放电然后再开机进系统。这个问题我踩过坑当时一台 ThinkPad 开了 VT-x 却没生效折腾半天才发现是没断电。3.2 第二步通过“Windows 功能”打开虚拟化支撑组件BIOS 层面没问题后下一步确认 Windows 功能。按下 Win R输入 optionalfeatures 回车打开“启用或关闭 Windows 功能”。这里需要重点确认以下几项Hyper-V如果系统是专业版、企业版、教育版可以勾选整个 Hyper-V 目录虚拟机平台Virtual Machine Platform这个非常关键Windows 虚拟机监控程序平台Windows Hypervisor PlatformWSL2 和 Hyper-V 兼容性相关适用于 Linux 的 Windows 子系统Windows Subsystem for Linux有些版本里 “Hyper-V” 和 “虚拟机平台” 是独立的两项有些版本里勾选“虚拟机平台”后会自动关联。保守做法是把上面提到的几项都勾上。如果你用的是 Windows 家庭版列表里可能看不到“Hyper-V”这一项这是正常的家庭版本身不带完整 Hyper-V但“虚拟机平台”和“适用于 Linux 的 Windows 子系统”这两项必须有。Docker Desktop 在家庭版上走 WSL2 后端跑 Linux 容器没有任何问题。勾选完成后系统会提示重启这里我建议一定重启不要点“稍后”。重启后先用第2部分的方法再确认一下 systeminfo 的输出看看四行要求是不是都变成了“是”。如果图形界面操作不方便也可以用管理员 PowerShell 执行命令效果一样Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux执行后依次输入 Y 并重启。如果命令报错 0x80070005那是权限不够确认 PowerShell 是否以管理员身份运行。如果报 0x800F0950多半是系统镜像文件有损坏需要先执行 DISM 修复DISM.exe /Online /Cleanup-Image /RestoreHealth修复完再执行 Enable-WindowsOptionalFeature。3.3 第三步安装/更新 WSL2 Linux 内核Windows 功能开完后下一步是确认 WSL2 内核。管理员 PowerShell 里先运行 wsl --status如果输出里有 “内核版本” 或者提示 WSL 版本太旧就直接更新。最简单的方式是从微软官方更新包安装。你可以在浏览器里搜索 “wsl_update_x64.msi 微软官方下载”下载后双击安装。安装完成后管理员 PowerShell 里再设置默认版本wsl --set-default-version 2如果你的 Windows 10 版本较新或者你用的 Windows 11其实可以不用手动下载更新包直接运行 wsl --update 让系统自动安装。这个命令在联网状态下会自动下载最新内核比手动找安装包省心。执行完后再看 wsl --version输出应该是一个比较新的版本号。还有一个小细节如果你之前装的是旧版 WSL系统里可能有“旧版 WSL 组件”和“新版 WSL”同时存在的混乱状态。稳妥的做法是先把已注册的发行版全部处理掉备份好数据然后在 Windows 功能里取消勾选旧版“适用于 Linux 的 Windows 子系统”重启后重新勾选再执行 wsl --install 或 wsl --update。这样做看起来麻烦但能避开很多非常奇怪的问题。3.4 第四步排查“内核隔离/内存完整性”的干扰前三步做完大部分机器就正常了。但还有一类机器虚拟化状态全开、WSL 也正常却依然报 “Virtualization support not detected”。这种情况我优先怀疑 Windows 内核隔离里的“内存完整性”。Windows 安全中心里有个“设备安全性”页面点进去能看到“内核隔离”再展开是“内存完整性”。它是 Windows 基于虚拟化安全的机制本质上是在虚拟化层之上再开一个安全区域。问题就在于当这个安全区域活跃时部分 Windows 版本上会和 WSL2 的虚拟化资源产生冲突Docker Desktop 动不动就检测不到虚拟化支持。如果其他排查都没问题可以试试把“内存完整性”关掉重启后启动 Docker Desktop 看看。关闭路径Windows 安全中心 → 设备安全性 → 内核隔离 → 内存完整性开关拨到关。如果你想用注册表方式路径是HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity找到 Enabled 键双击改成 0重启机器。改回来就是改成 1。这里要说明我不建议为了跑 Docker 一上来就关安全功能如果前面 BIOS、Windows 功能、WSL 内核都没问题Docker 仍然报错再考虑关内存完整性。毕竟安全性和开发环境哪个优先得自己权衡。不过从实际经验看很多 Windows 11 机器关掉内存完整性后 Docker 立刻恢复正常值得一试。4. Docker Desktop 自身配置与后端切换的细节4.1 确认 Docker Desktop 使用的是 WSL2 后端系统层折腾完还得看 Docker Desktop 自己的设置对不对。打开 Docker Desktop进 Settings齿轮图标切到 General 标签页找到 “Use the WSL 2 based engine” 这个勾选项。如果没勾选说明 Docker Desktop 打算用 Hyper-V 后端运行。问题在于很多人的 Windows 版本是家庭版根本没有完整的 Hyper-V 组件或者虽然开了 Hyper-V 但配置不完整这时候 Docker Desktop 就会报虚拟化支持未检测到。解决办法就是把勾打上改用 WSL2 后端。切换后端之后不要直接点 Docker Desktop 窗口的关闭按钮就完事了。右下角系统托盘里有鲸鱼图标右键选 “Quit Docker Desktop” 完全退出然后再重新打开。这样后端才真正切换过来否则有些配置不会立即生效。这里也顺便提醒一句Docker Desktop 设置里的配置改完后如果发现有提示需要重启 Docker一定要照做。很多人改完设置后直接继续操作结果发现 Docker 还是起不来其实是没有把配置真正刷进去。4.2 WSL Integration 与发行版挂载WSL2 后端跑起来之后还有个 Settings → Resources → WSL Integration 页面里面会列出当前系统里安装的所有 WSL Linux 发行版。把你需要用到的发行版开关打开。这个配置和 “Virtualization support not detected” 的报错没有直接关系。报错解决后如果你发现 WSL 里的 Ubuntu 等发行版访问不了 Docker或者 docker 命令在发行版里没反应基本都是这个 WSL Integration 开关没打开。还有一点要提醒Docker Desktop 在使用 WSL2 后端时会自动在 WSL 发行版里注册 docker 相关环境变量和 socket。因此正常情况下你不需要在 WSL 的 Ubuntu 里额外安装 docker-ce也不需要手动启动 docker 服务。如果你之前在 WSL 里手动装过 docker那反而容易和 Docker Desktop 的 docker 命令冲突遇到过几例这种奇怪折腾最后手动卸掉 WSL 里的 docker-ce 才正常。4.3 重装/重置 Docker Desktop 的正确姿势如果以上步骤都确认过Docker Desktop 还是报同样的错再考虑彻底重置。这里的操作顺序有讲究别上来就卸载。第一步右键托盘鲸鱼图标退出 Docker Desktop。 第二步管理员 PowerShell 里执行 wsl --shutdown把 WSL 虚拟机关掉避免打日志时文件被占用。 第三步备份数据目录。重点备份 C:\Users\你的用户名\AppData\Local\Docker 和 C:\Users\你的用户名\AppData\Roaming\Docker。 第四步控制面板里卸载 Docker Desktop。 第五步重启电脑重新安装最新版 Docker Desktop。 第六步启动 Docker Desktop看是否恢复正常。重置过程中不要慌。Docker Desktop 卸载时可能提示 Hyper-V 未启用之类的信息Docker Desktop 4.x 默认走 WSL2 后端不一定真的需要完整 Hyper-V。只要 WSL2 的组件都在卸载重装就能把败坏的配置清干净。这里我特别提醒一件事%LocalAppData%\Docker 目录里有个 wsl\data\ext4.vhdx 文件是 Docker Desktop 在 WSL2 里的虚拟磁盘里面存的是镜像、容器、卷的数据。重装时别手贱去删这个文件删了就是 Docker 所有数据全丢。我见过同事急眼了直接把整个 Docker 目录删掉结果本地几十个镜像全没了只能重新拉。5. 特殊环境的坑家庭版、虚拟机、残留组件与内核隔离5.1 Windows 家庭版到底怎么处理Windows 家庭版是 Docker Desktop 报错的重灾区因为网上大量教程一上来就说“勾选 Hyper-V”家庭版根本找不到这一项很多人到这一步就卡住了。事实是Docker Desktop 官方对 Windows 家庭版的支持方案就是用 WSL2 后端不需要完整 Hyper-V。家庭版需要做的只有两件事第一在 Windows 功能里开启“虚拟机平台”和“适用于 Linux 的 Windows 子系统”第二安装 WSL2 内核更新包并把默认版本设置为 2。做完这些Docker Desktop 在家庭版上就能正常运行 Linux 容器。需要注意家庭版开不了 Hyper-V所以跑不了 Windows 容器。如果你的工作场景必须用 Windows 容器比如开发 .NET Framework 应用那家庭版是真不行得升级到专业版或企业版。但如果只是日常跑 Linux 容器做开发测试家庭版加 WSL2 完全够用不用被网上那些“必须升级系统”的言论吓到。5.2 虚拟机里跑 Docker Desktop嵌套虚拟化有一种场景特别容易把人逼疯你的 Windows 本身是跑在虚拟机里的比如用 VMware Workstation 或 VirtualBox 装了 Windows再在 Windows 里装 Docker Desktop。这种情况下除了要保证虚拟机里的 Windows 虚拟化功能开好还要让虚拟机软件把物理机的虚拟化指令透传进去。VMware Workstation 的设置方法是虚拟机设置 → 处理器 → 勾选“虚拟化 Intel VT-x/EPT 或 AMD-V/RVI”。VirtualBox 的设置方法是系统设置 → 加速 → 勾选“启用嵌套分页”和“硬件虚拟化”。如果虚拟机软件里没有这个透传选项或者勾选了也不生效那 Docker Desktop 无论怎么配都会报 “Virtualization support not detected”。这里的原因不在 Windows 里而在虚拟机软件或者宿主机的 BIOS 层。做这一步之前建议先确认物理机 BIOS 的虚拟化开关是开着的否则虚拟机软件也没办法透传。个人经验在虚拟机里跑 Docker Desktop 的体验其实一般就算嵌套虚拟化配置成功性能也有损耗。如果只是学习 Docker推荐直接上物理机如果必须在虚拟机里跑优先用 VMware Workstation兼容性比 VirtualBox 稳一些。5.3 残留组件和旧版 Docker 清理还有一类情况是系统里残留了老旧的 Docker 相关组件。尤其装过 Docker Toolbox 的机器Docker Toolbox 是基于 VirtualBox 的老工具它会在系统里装上 VirtualBox 驱动和 com.docker.service 相关服务。这些残留组件和 Docker Desktop 的虚拟化检测逻辑会起冲突。排查方法是Win R 输入 services.msc看服务列表里有没有 Docker Desktop Service、com.docker.service 等 Docker 相关服务。再看看程序和功能里有没有遗留的 Docker Toolbox、老版 Docker Desktop。如果有先卸载干净再用我前面讲的重装姿势装新版本。另外系统里残留的 Hyper-V 组件也可能出问题。比如你之前创建过 Hyper-V 虚拟机后来删了虚拟机但没删 Hyper-V 功能或者反过来之前关掉过 Hyper-V但没重启这种情况下 Docker Desktop 检测到的虚拟化状态是混乱的。稳妥做法是确认需要哪些功能后统一在 Windows 功能面板里一次性勾选或取消然后重启机器避免开着半套组件。5.4 内核隔离与 VBS 深挖前面提过内存完整性这里把 VBS基于虚拟化的安全性再说深一点。VBS 是 Windows 利用硬件虚拟化在下层创建一个安全环境用来保护内核和敏感数据。它和 Docker Desktop 争抢的是同一套硬件虚拟化能力。判断 VBS 是否在运行打开“设置 → 系统 → 系统信息”拉到“基于虚拟化的安全性”如果显示“正在运行”就说明 VBS 已经启用了。这种情况下就算 BIOS 虚拟化显示已启用Docker Desktop 偶尔也会报虚拟化支持未检测到。处理方法是关闭“内核隔离”里的“内存完整性”这是 VBS 的主要用户态入口。如果关闭内存完整性还不够可以再考虑查看注册表HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity把 Enabled 设为 0重启。不过我提醒一句不要轻易使用 bcdedit /set hypervisorlaunchtype off 来关闭整个 Hypervisor。虽然这能暂时释放虚拟化资源但 WSL2 同样需要 Hypervisor关了之后 Docker Desktop 照样起不来。这种“杀敌一千自损八百”的操作只有在你完全确认只用 Hyper-V 后端、不用 WSL2 的时候才考虑。6. 问题速查表与个人排查顺序6.1 问题速查表把前面所有排查点整理成一张速查表方便后续照着做诊断信号指向原因首选处理任务管理器性能页显示“虚拟化: 已禁用”BIOS/UEFI 层未开启重启进 BIOS打开 VT-x/SVM断电重启systeminfo 中“虚拟机监控程序模式扩展: 否”BIOS 层未开启或 CPU 不支持检查 BIOS 设置或考虑 CPU 硬件是否满足systeminfo 中“已检测到虚拟机监控程序: 否”Windows 功能未启用勾选虚拟机平台、Hyper-V、Windows 虚拟机监控程序平台wsl --status 提示默认版本 1 或内核过旧WSL2 内核缺失安装 wsl_update_x64.msi 或执行 wsl --update设置默认版本 2安全中心“内存完整性”开启且 Docker 起不来VBS 与虚拟化资源冲突关闭内存完整性后重启测试虚拟机内运行且虚拟化透传未生效嵌套虚拟化未配置VMware/VirtualBox 设置中开启硬件虚拟化透传Docker Desktop 设置中 WSL2 引擎未勾选后端选择错误Settings → General → 勾选 Use the WSL 2 based engine完全退出重启Docker Desktop 重装后依旧报错数据残留或配置损坏备份数据后卸载清理 AppData 目录重装6.2 我推荐的排查顺序最后说下我自己的排查习惯。遇到 “Virtualization support not detected”我从来不直接重装 Docker Desktop而是按下面的顺序来第一步任务管理器性能页看虚拟化状态显示“已禁用”就直接进 BIOS其他都不用看。 第二步虚拟化已启用但还报错跑 systeminfo看四行 Hyper-V 要求是否全是“是”有“否”就去 Windows 功能里补勾。 第三步确认 Windows 功能都开了再执行 wsl --status 和 wsl --update把 WSL 版本拉新设成默认版本 2。 第四步启动 Docker Desktop如果还失败检查内核隔离和内存完整性关掉再试。 第五步检查是否虚拟机环境确认嵌套虚拟化透传开了。 第六步最后才考虑重装 Docker Desktop。这个顺序看起来慢实际上一台机器走完前三步最多十分钟。大多数人卡住是因为跳过了前面的基础设施排查直接去重装 Docker结果装完发现还是原来的报错白白浪费时间。你按我上面这个顺序来每改一处就对照速查表看一眼问题基本能定位到具体某一层。说个这次最深的体会Virtualization support not detected 这行字表面上属于 Docker Desktop深挖下去其实是 Windows 虚拟化链路的体检报告。链路哪层断了它就报哪层断。把这套链路摸透了以后别人再遇到这个错你看一眼电脑就能猜个大概方向。我自己现在处理这种问题平均不到五分钟就能定位大部分是 BIOS 被更新重置了剩下的是内核隔离开着在捣乱。先看硬件再看系统最后动 Docker 本身这顺序不会错的。