企业官网建设流程全解析

1. 为什么"重装"是件比想象中更麻烦的事

1.1 我这次重装 Docker Desktop 的真实起因

如果你纯粹是因为 Docker Desktop 提示版本过旧而打算重装，我建议先等一下。常规升级其实比重装安全得多，Docker Desktop 的安装包本身就支持原地升级，数据保留也更完整。我真正动了重装心思的诱因是：改了 WSL 的 .wslconfig 文件后，强制终止了 WSL 服务，然后又去手动执行了wsl --shutdown，结果 Docker Desktop 就一直卡在 "Starting the Docker Engine..." 状态。点 Restart 无效，升级无效，Troubleshoot 里始终显示 Docker Engine stopped。在这种状态下，最简单的办法就是卸载重装。

可真正让人崩溃的不是卸载，而是重装之后冒出来的各种"新问题"：原以为 Docker Desktop 的配置已经被清掉了，主界面干干净净，但启动后进程还在读旧的 daemon.json；镜像列表里一堆已经不存在的数据；有些人装完直接报 virtualization support not detected，而重装之前这个环境明明可以正常跑 Docker；还有人遇到 WSL2 后端起不来，原因是之前手动卸载过 Ubuntu 子系统，但虚拟交换机没有清理，导致 Docker Desktop 找不到可用的虚拟网络。

所以我把这篇整理成了"完整避坑流程"，而不是单纯一句"下载 exe 双击下一步"就完事。这篇内容对 Windows 10 和 Windows 11 都适用，包括 22H2 和 23H2 版本。如果你正打算重装，或者已经重装但启动失败，照着这个顺序走一遍，大概率能把问题控制在很小的范围内。如果你只是遇到 Docker Desktop 偶尔卡顿，还不至于走到重装那一步，也可以把文中的环境检查部分当作预防性检查来用。

1.2 重装前最容易被忽略的备份动作

官网文档一般只告诉你卸载会删除容器和镜像，但很少提醒你：volume 里的数据也会一并消失。Docker Desktop 在 Windows 上默认把数据放在 C:\Users\用户名\AppData\Local\Docker，这个目录一旦被清理，所有卷数据基本就找不回来了。如果你跑过数据库类容器（MySQL、PostgreSQL、Redis），这些数据往往是无法从镜像仓库重新拉取的，丢了就是真丢了。

我的操作习惯是：在卸载之前先把卷列表打出来，执行docker volume ls看有哪些项目单独创建的卷，再用临时容器的方式打包。举个例子，如果卷名叫 mysql-data，在 PowerShell 里执行：

docker run --rm -v mysql-data:/data -v ${PWD}:/backup alpine tar czf /backup/mysql-data.tar.gz -C /data .

这句命令的意思是把卷挂载到临时容器的 /data，再把当前目录挂载到 /backup，最后在容器内用 tar 打包。在 PowerShell 里执行时，%cd%这种 cmd 写法会失效，必须换成${PWD}，否则路径解析会报错，这是一个新手容易踩的小坑。如果你用的是 Compose 项目，建议先把 docker-compose.yml 里的卷定义复制出来，重装后直接照着重建。

对于镜像，我不会把所有镜像都docker save出来，因为大多数镜像都能从仓库重新拉取，重装后重新 pull 反而更干净。只有那些本地构建过、并且没有推到私有仓库的镜像，才值得用 docker save 做备份。备份完这些数据之后，才进入真正的卸载环节。

2. 卸不干净才是重装失败的元凶：一个完整的卸载流程

2.1 官方卸载之外的命令行清理

Docker Desktop 的 Windows 版本在卸载时，并不会把全部组件都移除。官方 exe 自带的卸载程序会移除主程序、服务以及大部分应用数据，但在实际使用中我发现至少有三类东西一定会残留：一是 C:\ProgramData\Docker 目录里的配置；二是 C:\Users\你的用户名\AppData\Local\Docker 里的数据目录；三是 Windows 功能组件，比如 Hyper-V、虚拟机平台、适用于 Linux 的 Windows 子系统这些功能不会被自动禁用。

为了保证卸载干净，我会在"设置→应用→安装的应用"里找到 Docker Desktop，先点击卸载，卸载完成后重启一次。注意一定要重启，不要想省这个时间，因为 Docker Desktop 的很多服务是在系统启动时被加载的，重启后再清理残留，才不会遇到文件被占用的报错。

重启之后打开命令行，以管理员权限执行几个检查命令。先看 Docker 相关的服务是否还在：

Get-Service *docker*

如果看到类似 com.docker.service 这样的服务还在，先确认它的路径来源确实是 Docker，再用下面的命令删除：

sc.exe delete com.docker.service

这里必须提醒一句，只有在确认是 Docker 残留服务时才删，不要随手把系统里其它服务也一并清了。接下来，把 C:\ProgramData\Docker、C:\Program Files\Docker、C:\Users\用户名\AppData\Local\Docker 这几个目录挨个检查，存在就手动删除。删除 AppData 目录时可能会遇到某些文件被进程占用的情况，如果在任务管理器里找不到相关进程，就用 PowerShell 的Remove-Item -Recurse -Force直接强删。

2.2 网络适配器和虚拟交换机残留处理

这是最容易被忽略的一步。Docker Desktop 在安装时会创建虚拟网络适配器，最常见的是 vEthernet (DockerNAT) 和 vEthernet (WSL)。如果你之前同时用过 Hyper-V 和 WSL2 后端，系统里可能还留着其它虚拟交换机。重装 Docker Desktop 后如果遇到网络相关的怪问题——比如容器访问不了外部网络、端口映射不生效——很有可能就是旧的虚拟交换机还占着原来的网段。

检查方法是在"控制面板→网络和共享中心→更改适配器设置"里看有没有 Docker 相关的虚拟网卡。确认存在后，不能直接乱删，因为 vEthernet (WSL) 其实是 WSL2 使用的虚拟交换机，卸载 Docker Desktop 之后，WSL 可能还需要用它。正确的顺序是：先打开管理员 PowerShell，执行wsl --shutdown，然后执行：

Get-NetAdapter | Where-Object {$_.InterfaceDescription -like "*Hyper-V*" -or $_.Name -like "vEthernet*"}

列出所有虚拟适配器，找到名字带 DockerNAT 或 Docker 的，确认后删除。但别用Remove-NetAdapter硬删，最简单可靠的办法是打开"设备管理器→查看→显示隐藏的设备"，在网络适配器里找到类似 Hyper-V Virtual Ethernet Adapter 的项，右键卸载。不过这个操作风险比较高，如果你不想碰设备管理器，也可以直接在网络适配器设置里把 DockerNAT 禁用，重装时 Docker Desktop 会重新创建新的适配器。

2.3 WSL 发行版的留与不留

重装 Docker Desktop 之前，要不要把 WSL 里的发行版也一起卸载？我的建议是：不要。

很多教程会告诉你"彻底重装就应该把 WSL 发行版也删掉"，但这是典型的过度清理。WSL2 是 Docker Desktop 的底层运行环境，它本身和 Docker Desktop 是独立的两层。你把 Ubuntu 或者其它发行版卸载后，并不会让 Docker Desktop 装得更顺利，反而会丢失你在 WSL 环境里配置过的工具链、SSH key、环境变量。稳妥的做法是保留 WSL 子系统，重装 Docker Desktop 后它会自动引导现有的 WSL2。

如果你确实怀疑某个 WSL 发行版损坏，也不要直接执行wsl --unregister，先在 PowerShell 里执行wsl -l -v查看发行版状态，再用wsl --export导出为 tar 格式备份，最后才考虑重新注册。Docker Desktop 默认使用的 docker-desktop 发行版是安装时自动创建的，它会在卸载时一并移除，重装后会自动重建，这个不用手动处理。

卸载和清理做完之后，再重启一次，然后进入下一阶段的环境检查。如果你跳过这个环节直接装，大概率会在第一次启动时踩到 virtualization support not detected 或者 WSL is unresponsive。

3. 宿主宿主机环境快检：虚拟化、WSL2、Hyper-V 以及 Windows 版本差异

3.1 先确认 CPU 虚拟化真的被打开了

很多人"重装失败"其实根本不是安装包的问题，而是底层的虚拟化被关闭了。在 Windows 里判断虚拟化是否开启，最简单的命令是打开 PowerShell 执行：

systeminfo

输出里能看到一行"Hyper-V 要求: 已检测到虚拟机监控程序。将不显示 Hyper-V 所需的功能。"这说明虚拟化已经开启。如果显示"固件中未启用虚拟化"，那问题就出在 BIOS/UEFI 设置上，需要进固件把 Intel VT-x 或 AMD SVM 打开。

需要注意的是，Docker Desktop 的错误提示 "virtualization support not detected" 有时候很误导。它可能不是指你 BIOS 里没开虚拟化，而是指当前 Windows 会话没有把虚拟机监控程序加载起来。最常见的两种情况：一是你在"启用或关闭 Windows 功能"里把 Hyper-V 关了；二是 Windows 安全中心的内核隔离（也就是内存完整性）开启后，基于虚拟化的安全功能（VBS）和 Hyper-V 产生冲突，导致 Docker 无法正常使用虚拟化能力。遇到这种情况，先不要急着进 BIOS，而是先检查 Windows 功能是否齐全，再检查 VBS 是否开启。

Windows 10 和 Windows 11 的路径不同。Windows 11 在"设置→隐私和安全性→Windows 安全中心→设备安全性→内核隔离详情"里可以查看内存完整性。Windows 10 则在"Windows 安全中心→设备安全性→内核隔离"里。如果这个选项是开启的，并且 Docker 启动失败，可以尝试暂时关闭内存完整性再重启测试。

3.2 启用 Windows 功能，以及功能之间的联动关系

把虚拟化确认打开之后，需要检查三个和 Docker Desktop 相关的 Windows 功能：Hyper-V、适用于 Linux 的 Windows 子系统、虚拟机平台。在 Windows 10 和 Windows 11 里都可以通过"启用或关闭 Windows 功能"窗口操作，运行 OptionalFeatures.exe 可以快速打开。

勾选建议如下表：

这里有一个常见误解，网上很多教程说"如果你只用 WSL2，可以不用开 Hyper-V"，这句话严格来说不完全对。WSL2 本质上就是运行在 Hyper-V 虚拟机平台上的，虽然你不需要手动去 Hyper-V 管理器里创建虚拟机，但底层的虚拟机监控程序必须存在。如果机器上只有 WSL1，那没问题；一旦升级到 WSL2，虚拟机平台就会一并启用。

在 Windows 10 的 20H1 以上版本和 Windows 11 中，比较快的操作方式是在管理员 PowerShell 里执行：

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

执行完后重启，再执行：

wsl --set-default-version 2

这一步非常关键。Docker Desktop 安装时虽然会尝试自动设置 WSL 2，但如果你系统里原本就存在 WSL1 的发行版，又没有把默认版本设为 2，Docker Desktop 启动时就会一直尝试用 WSL1 方式对接引擎，导致失败。

3.3 Windows 10 和 Windows 11 的差异点补充

Windows 11 上使用 Docker Desktop，最大的差异在右键菜单和终端。Windows 11 系统默认把很多操作收进了二级菜单，你右键 Docker Desktop 托盘图标时，部分选项看起来会少一些。网上有把右键菜单改回 Windows 10 样式的注册表改法，这里不展开讲，和 Docker 本身关系不大。值得提的是，Windows 11 的默认终端是 Windows Terminal，执行 wsl 命令时如果有多个发行版交互，建议用管理员权限的终端，否则你调用的 WSL 实例可能是用户态而不是系统态，权限不足会导致部分命令没有效果。

Windows 10 的老版本则要特别注意版本号。如果是 1903 或 1909 这种比较老的版本，对 WSL2 的支持不如 21H2 和 22H2 完善。重装 Docker Desktop 之前，建议把 Windows 10 至少升级到 21H2。如果你在老版本上遇到过 Docker Desktop 启动特别慢、资源占用异常的老问题，升级系统版本比重装 Docker Desktop 更有效。

另外，不管是 Windows 10 还是 Windows 11，如果你的系统做了精简优化（比如装了 LTSC 版本，或者手动禁用了 Windows 更新驱动），需要确认自己已经安装过 WSL 内核更新包。Docker Desktop 安装包会自动帮你装，但如果你先手动装过 WSL，又在更新设置里禁用了驱动更新，WSL 的内核文件可能一直停留在旧版本，导致 Docker Desktop 报 wsl 相关的模糊错误。安装前执行一下wsl --update算是成本很低但很有效的操作。

4. 安装 Docker Desktop 与第一次启动设置

4.1 安装包选择与安装参数

环境检查通过之后，去 Docker 官网下载 Docker Desktop for Windows 的安装包。注意区分稳定版和预览版，日常使用选稳定版就好。预览版适合想提前体验新特性的人，但稳定性和第三方工具的兼容性通常没有保证。

安装时双击 exe 文件，第一个勾选页面有两个选项：一个是 "Use WSL 2 instead of Hyper-V"，另一个是 "Add shortcut to desktop"。默认会勾选 Use WSL 2。如果你前面的环境检查发现 WSL2 确实没启用，但 Hyper-V 正常，可以考虑取消这个选项，使用 Hyper-V 后端。不过我的建议是：除非你有特殊理由必须用 Hyper-V 后端，否则优先使用 WSL2 后端。WSL2 启动速度快，资源占用更平滑，文件读写性能也更好。

如果要走命令行静默安装，可以关注这两个参数：

"Docker Desktop Installer.exe" install --quiet --accept-license --backend=wsl-2

在脚本化重装场景下，加 --backend=wsl-2 能跳过图形界面选择，直接装成 WSL2 后端。实际执行时我遇到过这种情况：明明加了参数，装完启动后仍然显示后端为 Hyper-V，原因就是当前系统里没有可用的 WSL2 发行版，安装程序自动回退到了 Hyper-V。解决方式是装完先执行wsl --set-default-version 2再重启，让 Docker Desktop 重新识别。

4.2 安装完成后不要急着点 Accept

安装完成后不要急着点进主界面，先把 Windows 安全中心里和 Docker 相关的目录加入排除项，再启动 Docker Desktop，能让启动过程省掉很多"卡在初始化"的麻烦。具体操作是："Windows 安全中心→病毒和威胁防护→管理设置→排除项"，把 %LOCALAPPDATA%\Docker 和 %ProgramData%\Docker 这两个目录加进去。

这里必须强调，只是加排除项，不是让你关闭实时保护。Docker Desktop 启动时需要创建 WSL 虚拟磁盘文件，磁盘文件通常有几个 GB 大小，如果安全软件在启动时对这些文件做实时扫描，启动时间会被拖得很长，甚至直接导致启动超时失败。加白名单之后，这个问题基本就不会出现了。

第一次点击 Docker Desktop 图标，会进入一个初始化流程，包括接受服务条款、选择是否发送使用诊断数据。这些流程走完后，Docker Desktop 会创建 docker-desktop 和 docker-desktop-data 两个 WSL 发行版，这个创建过程可能需要一两分钟，不要中途关闭窗口。如果你等了很久还在转圈，打开 PowerShell 执行wsl -l -v，如果能看到这两个发行版的状态是 Running，就说明创建成功；如果状态是 Stopped，手动执行wsl --shutdown再启动 Docker Desktop。

4.3 首次启动时的后端选择逻辑

Docker Desktop 的安装包自带一整套"首次启动向导"，但向导并不会每次都问你"选 WSL2 还是 Hyper-V"。如果你安装时勾选了 Use WSL 2，安装程序会自动配置 WSL2 后端；如果没勾选，就会尝试使用 Hyper-V 后端。第一次启动时，它会先检查本机是否满足所选后端的要求，不满足就直接弹错误对话框。

很多人在这一步遇到的问题是"我明明装了 WSL2，怎么还是提示需要启用 Hyper-V"。这个提示有可能是假的。Docker Desktop 在检查 WSL2 后端时，给出的错误文案经常会在中文环境下错误地显示成类似"virtualisation support wasn't detected"的意思，实际根因可能是 docker-desktop 这个 WSL 发行版没有正确初始化。解法是手动到命令行执行：

wsl --shutdown

然后重新启动 Docker Desktop。如果还不行，就到 %LOCALAPPDATA%\Docker 下删除 wsl 相关的临时发行版目录，让 Docker Desktop 重新创建。这一步我试了很多次，最简单可靠的方法其实是干脆从 Docker Desktop 设置里 Reset to factory defaults。不过我理解很多人对重置有顾虑，所以把它放在后面讲，能不用重置就不重置。

5. 第一轮启动失败：高频错误与排查链路

5.1 "Virtualization support not detected"的完整排查链路

这个错误是 Docker Desktop 在 Windows 上最经典的拦路虎。报错文案不一定是中文的，但常见形式是 "Docker Desktop failed to start because virtualization support wasn't detected" 或者 "Virtualization support not detected"。看到这个，第一步不是进 BIOS 折腾，而是照着下面的顺序排查。

先看 Windows 是否真的开启了虚拟化。用 systeminfo 命令最直观。如果 systeminfo 显示"已检测到虚拟机监控程序"，说明 CPU 虚拟化层面没问题。第二个可能是 Windows 功能里的"虚拟机平台"没启用。这个功能在 Windows 10/11 里和 WSL2 强相关，没启用时，Docker Desktop 会直接报 virtualization support not detected，尽管 systeminfo 显示虚拟化正常。

如果上面两项都查了还报错，就要考虑内核隔离和 Hyper-V 的冲突。Windows 安全中心里的"内存完整性"开启后，会使用基于虚拟化的安全功能（VBS）。VBS 启动时会占用虚拟化能力，和 Hyper-V 的角色存在竞争。在部分机器上，Docker Desktop 启动时发现虚拟机监控程序被 VBS 占用，就会给出这个错误提示。尝试关闭内核隔离并重启，看问题是否解决。

最后，如果还是不行，检查固件里 SVM（AMD）或者 VT-x（Intel）是否被虚拟化软件先占了。特别是装了 VMware Workstation 的用户，虚拟机的"虚拟化引擎"里有一项"虚拟化 Intel VT-x/EPT 或 AMD-V/RVI"，如果勾选了，会产生嵌套虚拟化的状态，反而干扰 Docker Desktop 对底层虚拟化能力的判断。在 Windows 10/11 上同时跑 VMware 和 Docker Desktop 的时候，这种问题尤其常见。

5.2 "WSL is unresponsive"：别急着重置

"Docker Desktop - WSL is unresponsive" 这个错误在重装后的出现频率很高。它描述的现象是 Docker Desktop 与 WSL2 之间的通信断了，但底层 WSL 发行版可能还活着。

常见原因是 Docker Desktop 尝试连接 WSL 时，WSL 实例处于挂起状态或内存耗尽。在 PowerShell 里执行wsl -l -v，如果发现 docker-desktop 发行版的状态是 Stopped，先执行wsl --shutdown，再重新启动 Docker Desktop。如果状态是 Running 但 Docker Desktop 还是报 unresponsive，可以执行wsl -d docker-desktop进入这个发行版，看看里面是否还有 docker 相关进程在跑。不过一般用户不需要进入这个发行版做操作。

更隐蔽的原因是 Windows 本地的探针端口被占用。Docker Desktop 会通过本地 socket 和 WSL 通信，如果电脑上装了某些网络代理工具、加速器或者抓包软件，占用了相关端口后，Docker Desktop 就会报 unresponsive。此时可以临时退出这些网络工具，再重启 Docker Desktop 测试。另外，不要为了访问海外资源就手动修改 vEthernet (WSL) 这个虚拟网卡的 DNS 或者 IP 配置，一旦改乱了，Docker Desktop 与 WSL 之间的通信就会变得极其不稳定。本文不展开任何代理工具的配置方法，只是提醒：你自己改过的网络配置很可能就是干扰源。

如果前面的排查都做完了还是无响应，在确定没有重要容器数据的前提下，打开 Docker Desktop 的 Troubleshoot 页面，选择 Reset to factory defaults。这个操作会把 Docker Desktop 恢复到初始状态，相当于再做了一次更干净的"重装"，耗时五到十分钟。

在这个问题上，我的建议是先排查通信层，不要一上来就重置。重置虽然能解决 70% 的问题，但代价是丢失所有配置和本地数据，对重装用户来说无异于雪上加霜。

5.3 Docker Engine 起不来的日志解读

另一种很常见的启动失败是：Docker Desktop 界面能打开，但左下角一直显示 "Docker Engine is starting"，一分钟后变成 "Docker Engine stopped"。进入 Troubleshoot 可以查看日志，但日志文件在 %LOCALAPPDATA%\Docker\log\ 目录下，里面的 txt 文件非常多，第一次看的人容易摸不着头脑。

我的经验是直接找 host 前缀的日志文件，看里面是否有明显的错误行。比如 "Failed to start WSL2" 或者 "open //./pipe/docker_engine: The system cannot find the file specified."。后者一般表示 Windows 主进程和引擎之间的命名管道没有建立，原因通常是安全软件拦截了 Docker Desktop 创建命名管道的权限，或者之前残留的旧服务还在占用管道。

遇到这类问题，第一件事是关闭所有可能做系统级拦截的软件。不是让你禁用安全中心，而是说如果你装了第三方安全软件、电脑清理软件，最好在设置里把 Docker Desktop 加进白名单。再把前面删除残留目录的步骤重新做一遍，尤其是 %ProgramData%\Docker，这个目录里的旧配置可能让新装的 Docker Desktop 读取到旧的环境定义，导致引擎启动直接崩溃。

日志里如果出现 "vmcompute service cannot be started" 这行字，表示 Hyper-V 主机计算服务启动失败。在管理员 PowerShell 里执行：

net start vmcompute

看看具体报什么错误。如果提示拒绝访问，可能是服务的启动类型被修改成了禁用。打开 services.msc，找到 Hyper-V Host Compute Service，把启动类型改成自动，再手动启动一次，然后重新打开 Docker Desktop。

5.4 安全软件排除项与防火墙规则

Windows 自带的安全中心和第三方安全软件，在 Docker Desktop 的重装过程中扮演的角色很容易被低估。很多启动失败、容器网络异常，追根溯源就是安全软件的实时防护或主动防御模块在拦截 Docker 创建虚拟磁盘、写注册表、建立虚拟网络适配器。

如果你在日志里看到类似 "Access is denied"、"Operation not permitted" 这类权限错误，优先检查安全软件的拦截日志。把 C:\Program Files\Docker、C:\ProgramData\Docker、%LOCALAPPDATA%\Docker 这三个路径全部加进白名单，再把 Docker Desktop 的主程序文件 Docker Desktop.exe、com.docker.service 都加进去。加完白名单后重启一次 Docker Desktop，很多时候能解决莫名其妙的启动失败。

防火墙方面，Docker Desktop 安装时会自动添加相关的防火墙入站规则。如果重装之后容器内访问外网超时，但宿主机上网正常，先检查"高级安全 Windows Defender 防火墙"里有没有 Docker Desktop 的入站规则。如果没有，可以手动把 Docker Desktop.exe 加入允许列表。另外，容器端口映射后如果外部机器访问不到，除了检查 Docker 的端口映射参数，还要确认 Windows 防火墙没有拦截对应的 TCP/UDP 端口。

6. 重装完成后的资源配置与 C 盘空间问题

6.1 第一次正常启动后，我建议你立刻做的几件事

当 Docker Desktop 主界面终于显示绿色运行状态时，不要急着拉大镜像。先打开 PowerShell，执行docker version，确认 client 和 server 两部分都正常显示。如果 server 信息缺失，说明引擎还没完全就绪，再等几秒或者查看刚才提到的日志。

接着执行docker run hello-world跑一次官方测试镜像，如果能正常返回说明容器的创建、启动、网络通信全链路是通的。这一步能帮你把问题边界划得很清楚：如果 hello-world 能跑，说明 Docker 本身没问题，后面遇到任何怪问题都是项目配置层面的，别再去折腾 Docker Desktop 了。

还需要注意一点，重装后docker context ls的默认上下文可能显示为 desktop-linux，这是正常的。如果你之前在 Docker Desktop 里玩过远程上下文（Docker context 连接远程服务器），重装后默认会切到本机上下文，这种变化不需要处理。但是当你回到项目目录执行docker compose up -d时，要确认当前上下文确实指向本机，不然命令可能发到了远程机器上。

6.2 镜像加速配置的重新填写

重装后镜像拉取速度变慢是很常见的，因为之前的镜像加速地址可能丢了。Docker Desktop 的 registry-mirrors 配置写在 daemon.json 里。"Settings→Docker Engine"标签页会展示一段 JSON，在里面加入：

{ "registry-mirrors": ["替换成你实测可用的加速地址"] }

填写之前，我建议先在浏览器里访问一下加速地址的连通性。现在很多老地址已经失效，如果你从网上随手复制几个地址填进去，Docker 拉取镜像时会不停尝试这些镜像源，反而比直连更慢。我之前遇到过一次，填了三个失效地址，拉一个镜像卡了十分钟报 timeout，去掉这些地址后秒拉。填配置时也要注意 JSON 格式，漏一个逗号或者多了大括号，Docker Engine 直接拒绝启动。

6.3 数据目录迁移到非系统盘

很多人重装前会纠结 Docker Desktop 是不是只能装在 C 盘。官方安装包默认确实只能把主程序装在 C 盘，但数据目录是可以改位置的。在 Docker Desktop 的设置里，Settings→Resources→Advanced 页面，可以修改 Disk image location，把 WSL 虚拟磁盘放到的 D 盘或者其他空间充足的盘。

这个操作对 C 盘紧张的用户非常实用。Docker 的虚拟磁盘文件会随镜像和卷的增长变得很大，如果你长期拉镜像、构建镜像，C 盘很容易被吃满。建议新装的 Docker Desktop 在拉取大量镜像之前，先到 Disk image location 里把存储位置改到非系统盘，改完会提示需要重启 Docker Desktop，确认就行。

需要注意，改 Disk image location 时会触发 Docker Desktop 移动现有数据。如果原来的数据已经很大，移动过程会比较耗时，期间不要强制关机，否则虚拟磁盘文件可能损坏。移动完成后，可以在资源管理器里确认目标盘目录下出现了 docker-desktop-data 的 vhdx 文件，大小和你之前的数据量基本一致，说明迁移成功。

6.4 WSL2 内存限制的配置建议

Docker Desktop 默认会使用宿主机相当一部分内存。如果你的机器是 16GB 内存，Docker Desktop 可能会分配 8GB 给 WSL2 虚拟机，Windows 本身再用一部分，整机就会明显变卡。重装干净之后，是设置内存上限的好时机。

在用户目录下创建一个 .wslconfig 文件，内容可以这样写：

[wsl2] memory=6GB processors=4 swap=2GB

这个文件会影响所有 WSL2 发行版，包括 Docker Desktop 的 docker-desktop 发行版。设置完成后执行wsl --shutdown，然后再启动 Docker Desktop，内存限制才会生效。如果填的值太低，构建容器时可能出现内存不足的报错，比如 "Killed" 或者 exit code 137，这时候适当调高 memory 值就行。

个人经验是，8GB 内存的机器建议给 Docker 分配不超过 4GB，16GB 内存的机器给 6~8GB 比较合适，32GB 以上内存的机器可以放心给到 12GB 以上。这个数值没有绝对标准，取决于你的容器负载。如果你只跑两三个轻量容器，甚至可以把内存限制在 2GB 以内，给宿主机留出更多余量。

7. 重装中常见的周边问题：Win10 优化、LTSC 等特殊环境

7.1 为什么 Win10 优化设置可能把 Docker 优化没

重装 Docker Desktop 的用户里，有一部分是装过"Win10 优化设置"的，比如用各种脚本工具禁用后台应用、关闭 Windows 更新、禁用系统服务来提升性能。这些优化对小内存老机器有一定作用，但很可能把 Docker Desktop 需要的底层服务也一起禁用了。

最典型的是 Windows Update 服务。WSL2 的内核更新依赖 Windows 更新机制，如果你用工具把 Windows Update 彻底禁用了，wsl --update就装不上新内核，Docker Desktop 启动时可能因为内核版本不对而失败。另外，一些优化脚本会禁用 Hyper-V 相关服务或者计划任务，导致 Docker Desktop 启动时报 Hyper-V 错误。

如果你已经在优化过的 Win10 上重装 Docker Desktop，先别急着重装系统，按下面的顺序检查：确认 Windows Update 服务没有被禁用（services.msc 里看 wuauserv 的状态），确认 Hyper-V Host Compute Service 存在并且启动类型是自动，确认 虚拟机平台 和 适用于 Linux 的 Windows 子系统 功能都是开启状态。这几项过关后，大多数优化导致的 Docker 启动失败都能解决。

7.2 LTSC 2021 上的 Docker Desktop 安装注意事项

Win10 LTSC 2021 在企业环境中用得不少，但它是长期服务版，默认不带 Microsoft Store，也不包含 WSL2 所需的全部组件。网上有帖子讨论 Win10 LTSC 2021 禁用后台应用后怎么装 Docker，这里提几个实际踩过的点。

LTSC 2021 缺少 Store 应用商店，而 WSL2 的官方安装方式之一是从 Store 安装。对于 LTSC，需要手动下载 WSL 的安装包，或者用 dism 命令启用功能，再单独安装 WSL 内核更新包。Docker Desktop 的安装程序本身也带 WSL 组件，但在 LTSC 上它不一定能自动装好，所以最稳妥的路径是：先执行wsl --install --no-distribution或者手动启用功能，装好内核后，再执行wsl --set-default-version 2，最后安装 Docker Desktop。

LTSC 版本如果禁用后台应用，也要留意 Docker Desktop 的计划任务和开机启动。如果你禁用了后台应用，Docker Desktop 启动前最好手动点开主界面，确认托盘图标能正常出现。企业环境里如果权限受限，安装时右键"以管理员身份运行"也很有必要，因为 Docker Desktop 要写 ProgramData 和创建 Windows 服务。

7.3 关于 Win10 系统重装和虚拟机安装工具的连带思考

有一些朋友是在折腾 Win10 虚拟机或者给另一台机器装 Win10 的过程中，发现 Docker Desktop 不能用了。这种情况下的问题往往不是 Docker Desktop 本身，而是宿主机的 CPU 虚拟化被虚拟化软件占用了。比如你在 VMware 或 Hyper-V 的虚拟机里装 Win10，又想在虚拟机里跑 Docker Desktop，那就要开启"嵌套虚拟化"功能。

VMware 里开启嵌套虚拟化，需要在虚拟机设置中勾选"虚拟化 Intel VT-x/EPT 或 AMD-V/RVI"；Hyper-V 里则需要在 PowerShell 对对应的虚拟机执行：

Set-VMProcessor -VMName "你的虚拟机名称" -ExposeVirtualizationExtensions $true

开启之后再进虚拟机的 Win10/Win11，执行wsl --update和 Docker Desktop 安装，才可能成功。不开启嵌套虚拟化的话，虚拟机里的 systeminfo 会显示"固件中未启用虚拟化"，Docker Desktop 自然起不来。

如果你用的是 WinNTSetup 等工具自己装的精简版 Win10，建议装完系统先确认几个关键功能完整：Hyper-V、虚拟机平台、WSL、Windows 安全中心。精简系统经常把这些组件删掉，补装起来比较麻烦，甚至需要重装完整的原版 ISO。重装 Docker Desktop 前发现系统组件缺失，再折腾安装包也是白费功夫。

8. 一些个人经验和最后的建议

整套流程走下来，我最深的感受是：重装 Docker Desktop 最大的风险不是在安装环节，而是在你自以为"卸干净了"的那一刻。残留的服务、残留的虚拟交换机、残留的 AppData 配置，任何一个都可能在重装后给你出其不意的报错。所以这篇文章花了比较大的篇幅讲卸载和清理，希望你能理解这一步的价值。

另外，遇到报错时，不要一上来就重置。Docker Desktop 的 Troubleshoot 页面提供了导出日志的功能，先看日志，再去搜索引擎搜具体的错误行，比把你的问题截图丢到社群里问一句"怎么办"要有效率得多。报错信息的英文关键词往往就是答案。比如 "vmcompute" 直达 Hyper-V 服务，"docker_engine: Access is denied" 指向权限问题，"context deadline exceeded" 多半是网络或代理问题。

还有一点，重装完 Docker Desktop 后，不要急着把所有旧项目一次性启动。先跑一个最简单的容器确认引擎健康，再把 Componse 项目逐个起。这样可以避免多个容器同时启动时资源竞争，一旦出问题也容易定位是哪个服务的配置有误。

如果你在这台 Windows 上既用 Docker Desktop，又用 VMware 或其它虚拟化软件，建议给它们做一个明确的分工。比如 VMware 里的虚拟机平时不开启，需要时再启动；Docker Desktop 在启动状态下，避免同时启动多个重量级虚拟机，不然 CPU 和内存都会很紧张。

关于 Docker Desktop 的汉化，官方界面本身没有中文选项设置，但现在的几个社区汉化包流行度比较高，如果你不习惯英文界面可以找找看。不过我个人建议还是尽量适应英文界面，因为 Docker 的配置文件、日志、错误信息几乎全是英文，你习惯了界面英文之后，看日志也会顺很多。

最后再说一个小技巧：重装完并确认环境健康后，用docker system df看一眼当前的磁盘占用情况，记下基线数值。以后发现磁盘涨得厉害，拿当前值跟基线对比，能快速判断是镜像、容器还是卷空间在涨。这个动作成本很低，但对后续的磁盘空间管理帮助很大。

希望这篇整理能让你这次的 Docker Desktop 重装，最多半小时就结束。如果过程中真的又碰到了哪些没写到的报错，欢迎带着日志内容来交流，一起把坑填平。