同事把一台刚配好的笔记本推到我面前说 Docker 装了三遍装完就卡在启动界面转圈让我帮忙看看。我打开任务管理器,切到性能标签,点开 CPU,右下角一行小字写着虚拟化已禁用。从接手到定位问题不到十秒,但后面把虚拟化打开、让 WSL2 组件补齐、再把虚拟磁盘从 C 盘挪走,前后折腾了小半个下午。这就是 Windows10环境下安装Docker 这件事的真实面貌:安装包本身不复杂,复杂的是它踩在 Windows 虚拟化栈、WSL 子系统、磁盘布局这几个东西的交界处,任何一个环节没对齐,表现都是同一种样子——转圈。这篇内容写给两类人:一类是第一次在自己的 Win10 机器上装 Docker、希望一次跑通不返工的;另一类是装过了但用起来别扭,比如机器越跑越卡、C 盘莫名其妙少了几十 G、项目目录挂载进去读写慢得离谱,想回头把配置理顺的。下面从选型讲到排错再到日常调优,每一步我都会说清楚为什么要这么干,以及我在实际操作中踩过哪些坑。1. 先把选型定下来Win10 上跑的到底是个什么 Docker很多人默认装 Docker就是把一个客户端软件装到 Windows 上,然后像开 QQ 一样打开它。这个认知偏差会直接导致后面所有的困惑:为什么它要占好几个 G 内存?为什么它要改我的网络配置?为什么卸载它还要单独清理别的东西?所以动手之前,先把这层关系捋清楚,后面九成的排错思路都从这里来。1.1 Hyper-V 后端和 WSL2 后端,差的不只是一个勾Docker 的守护进程本质上是一个 Linux 程序,Windows 内核跑不了它,所以必须在 Windows 上先造出一个 Linux 环境,把守护进程放进去。历史上官方给过两条路子:早期用 Hyper-V 建一台轻量虚拟机,后来改用 WSL2 作为默认承载。这两种方式在安装向导里就是一个勾选项的区别,但实际体验差别不小。Hyper-V 后端相当于在你机器上开了一台看不见的虚拟机,启动慢一点,内存占用是整块划走的,好处是隔离性强、和 Windows 文件系统打交道的方式更接近传统虚拟机。WSL2 后端则是一个由系统托管的轻量 Linux 子系统,启动快、内存是按需动态分配的、和 Windows 的文件互访更顺滑,代价是它的动态内存回收策略有时候过于保守,会把吃下去的内存攥着不放。我现在的默认建议很明确:只要能选 WSL2,就选 WSL2。理由有三个:一是家庭版 Windows 没有 Hyper-V 管理面板,WSL2 后端是家庭版用户唯一顺畅的路;二是 WSL2 后端下\\wsl$路径访问项目文件比虚拟机共享文件夹方便得多;三是后续做多容器编排、挂载本地代码目录调试时,WSL2 的 inotify 文件变更通知能正常传进去,热重载才不会失效——这一条在 Hyper-V 后端下经常要额外折腾。至于我全都要的念头,趁早打消。同一台机器上 Docker Desktop 只能选一种后端,切换后端意味着重置整个容器数据,已经拉好的镜像和跑着的容器会全部消失。所以在第一次安装向导里就把这个选项定死,别抱着试试看的心态来回切。1.2 用三条命令确认你的机器够不够格官方文档里的系统要求看着长,实际需要你确认的就三件事:系统版本号够不够、CPU 虚拟化开没开、内存和磁盘余量够不够。这三件事我习惯用最短路径确认,不开一堆面板乱翻。第一条,按Win R输入winver回车,弹窗里那串版本号就是你的实际系统版本。近两年的 Docker Desktop 版本对 Win10 的门槛已经抬到 22H2 及以上,如果你的机器还停在 1909、2004 这类老版本,先在设置里把系统更新跑完再谈装 Docker,否则安装程序会直接拒绝或者装完各种诡异报错。第二条,Ctrl Shift Esc打开任务管理器,性能标签里点 CPU,看虚拟化那一行。这一行是已启用才算过关,已禁用意味着你得进 BIOS 打开它,下面 2.1 节会细说。同一个页面往下看内核隔离里的内存完整性,如果它是开着的,在某些机型上会和虚拟化组件产生冲突,表现为虚拟机平台启动失败,这个后面 4.3 节展开。第三条,看资源余量。给 Docker 留的空间,我的经验值是:内存至少 8G 起步、16G 比较舒服;磁盘上,光安装包加基础镜像就要 8 到 10G,如果你打算跑数据库类的镜像,再留 30G 不算多。一条systeminfo | findstr /C:Total Physical Memory就能看到物理内存总量,磁盘余量直接看资源管理器更直观。检查项命令或位置合格标准不合格的后果系统版本winverWin10 22H2 及以上安装被拒或运行异常CPU 虚拟化任务管理器 → 性能 → CPU显示已启用后端起不来,卡在启动物理内存systeminfo建议 16G多容器时整机卡顿系统盘余量资源管理器建议 30G 以上镜像堆积后磁盘告急这三条确认完,基本上就把后面 80% 的装不上提前排除了。剩下的 20% 藏在系统功能开关和组件版本里,下一节讲。2. BIOS到系统开关真正决定安装成败的前置条件新手最容易犯的错误是:下载完安装包直接双击,一路下一步,然后对着转圈的界面发呆。安装程序不会告诉你你的虚拟化没开,它只会用一个永远转不完的进度条表达抗议。所以正式安装之前,把这一层的开关全部对齐,是最省时间的一步。2.1 虚拟化在 BIOS 中被关掉的典型症状出厂默认关闭虚拟化是很常见的做法,尤其是部分轻薄本和整机预装的系统,厂商出于功耗或安全策略会把它关掉。判断方法前面说过,任务管理器看那一行。如果显示已禁用,重启进 BIOS 去找对应选项。不同厂商的叫法五花八门,常见的有Intel Virtualization Technology、VT-x、SVM Mode、AMD-V,一般藏在 Advanced、CPU Configuration 或者 Security 这几个菜单下。进去改成 Enabled,保存退出重启。个别机型还有一层VT-d或者IOMMU,这个不是必须的,不用管它,但如果你后面要跑需要直通设备的场景,可以顺手一起打开。打开之后回到任务管理器确认那一行变成已启用。这里有个容易被忽略的细节:某些机器在 BIOS 里打开了,但系统里因为内核隔离或者设备保护的策略,虚拟化仍处于受限状态。表现是 Hyper-V 平台能装但启动报错,或者 Docker Desktop 装完后提示虚拟机平台不可用。这种时候去 Windows 安全中心 → 设备安全性 → 内核隔离详细信息,把内存完整性临时关掉再试,能启动就说明是这个冲突,后面 4.3 节会讲怎么权衡。提示:改 BIOS 之前先把 BitLocker 的恢复密钥确认能拿到。部分机型改完 BIOS 会触发恢复密钥验证,拿不到密钥就进不去系统,这个坑比 Docker 装不上严重得多。2.2 启用或关闭Windows功能里勾哪几个、别勾哪几个这一步是整个安装里最容易勾错的地方。搜索框里输入启用或关闭 Windows 功能,打开那个经典的小窗口,列表里和 Docker 相关的有三个:Hyper-V、虚拟机平台、适用于 Linux 的 Windows 子系统。三者的关系是:虚拟机平台:提供底层虚拟化能力,WSL2 依赖它,必勾。适用于 Linux 的 Windows 子系统:WSL 本体,必勾。Hyper-V:只有你打算用 Hyper-V 后端跑 Docker,或者要用 Hyper-V 管理面板时才勾。这里的关键判断是:如果你走 WSL2 后端,Hyper-V 那一项可以不勾。勾上它的副作用是它会独占虚拟化层,和某些版本的 VMware、VirtualBox 抢资源,导致那些虚拟机软件要么启动失败,要么性能掉一大截。我见过太多人图省事三个全勾,结果装完 Docker 发现原来的虚拟机全罢工了,又回头一个个排查。勾完之后系统会要求重启,重启后打开命令行执行wsl --status,如果能看到默认版本:2这一行,说明底层链路是通的。如果提示找不到命令,说明子系统组件没装好,回退去检查勾选项;如果默认版本显示 1,执行wsl --set-default-version 2改过来。这一步做完,前面的准备工作才算真正结束。2.3 家庭版没有Hyper-V面板时的绕行思路Win10 家庭版的控制面板里根本看不到 Hyper-V 那一项,很多人以为家庭版装不了 Docker,这是个流传很广的误解。事实是:家庭版完全支持 WSL2,而 Docker Desktop 走 WSL2 后端时并不需要 Hyper-V 那一套图形化组件。需要的操作就是前面说的两项:虚拟机平台和适用于 Linux 的 Windows 子系统,家庭版这两个都能勾。勾完重启,wsl --status能出结果就说明环境就绪,直接去装 Docker Desktop,安装向导里把Use WSL 2 instead of Hyper-V勾上(新版向导会根据你的系统自动判断,家庭版只会给你 WSL2 这一个选项)。这里有个细节值得提前说:有些老版本的 WSL 内核组件是随机附带的残缺版本,wsl --status能出结果但 Docker 启动时报WSL 2 installation is incomplete。解决办法是从命令行跑一次wsl --update,让系统把内核和运行时更新到当前版本。这个命令在 Win10 上偶尔会因为系统组件版本太老而失败,失败的话就手动下载那个内核更新包装上,装完重启,问题基本就解决了。这条报错我在不同机器上遇到过五六次,基本都是这一个原因。3. 安装实操从安装包到第一条docker run跑通前置条件全部对齐之后,安装本身是整篇文章里最快的一段,五分钟能走完。但快不代表可以一路无脑下一步,向导里有两三个选项会影响你后面几个月用起来顺不顺,值得停下来看一眼。3.1 安装包获取与安装位置的取舍安装包从官方渠道下载,不要用来路不明的精简版绿色版。原因很实在:Docker Desktop 的安装过程会同时注册系统服务、写注册表、配置 WSL 分发,任何一个环节被精简掉,后面都会以各种诡异形式反噬。而且这东西更新频率高,非官方包的版本滞后,遇到问题去查文档对不上号。安装位置默认在系统盘的Program Files,这个不建议改。Docker Desktop 的程序本体只有一两个 G,真正吃空间的是镜像和容器数据,那部分在安装时可以单独通过设置页迁走,或者用后面 5.1 节说的方法处理。把程序本体挪到别的盘反而可能触发权限和路径问题,得不偿失。安装向导里还有一个Add shortcut to desktop和Add Docker to your PATH的选项,Path 那个一定要勾,否则你在 PowerShell 里敲docker会提示不是内部或外部命令,还得手动配环境变量。勾完装完记得把已经打开的终端全部关掉重开,环境变量的变更对新开的进程才生效——这个细节坑过不少人,装完在旧窗口里敲命令提示找不到,以为装失败了。3.2 首次启动向导里那几个勾选项该不该勾装完第一次启动,会走一个配置向导。里面几个选项我逐条说我的选择:Use WSL 2 instead of Hyper-V—— 勾,理由前面说过。家庭版只有这个选项。Enable WSL 2 based engine—— 同上,这是一回事。Send usage statistics—— 随意,不影响功能。Start Docker Desktop when you log in—— 建议勾上。不勾的话每次开机要手动启一次,守护进程没起来,任何 docker 命令都会报 cannot connect to the Docker daemon。当然,如果你只是偶尔用,不想让它常驻吃内存,可以不勾,用的时候手动开。Expose daemon on tcp://localhost:2375 without TLS——绝对不要勾。这个选项的意思是让守护进程监听一个明文 TCP 端口,本机任何程序(包括浏览器里跑的脚本)都能连上来执行任意容器操作,等于把机器控制权敞开。有些人为了用某些图形化管理工具方便就勾上了,这是典型的为了方便牺牲安全。真需要远程访问,走 SSH 隧道或者配 TLS 证书,别用这个。向导走完,Docker 会自己拉一个 hello-world 镜像做自检。这一步如果卡住不动,先别急着重装,看下一节。3.3 四条命令验证安装完整性托盘图标变绿只能说明守护进程活着,不代表整条链路是通的。我习惯用四条命令做完整验证,顺序也有讲究:# 1. 客户端与服务端版本是否都拿到了 docker version # 2. 守护进程的详细配置,重点看 Storage Driver 和总内存 docker info # 3. 完整跑一次拉取-创建-启动-输出的链路 docker run --rm hello-world # 4. 检查 compose 插件是否就位 docker compose version第一条最容易看出问题:如果只输出了 Client 部分、Server 部分报错,说明客户端装好了但守护进程没起来,去查 WSL 状态;如果两部分都正常,链路基本是通的。第二条里的docker info值得认真看几眼。Total Memory会告诉你 Docker 能用多少内存——这个数字往往比你机器的物理内存小不少,因为它是从 WSL2 子系统里读的,而 WSL2 默认只拿一半。Storage Driver在新版本里通常是overlay2,如果你看到的是别的驱动,说明后端配错了,得回头查。Docker Root Dir这一行给出镜像实际存放的位置,后面迁数据就靠这个路径。第三条是最终验收。hello-world这个镜像只有几十 K,如果它能跑通,说明拉取、存储、运行、网络这一整条链路都活着。跑不通的话,报错信息基本能直接指向问题类型,下一节按报错分类。第四条单独列出来是因为 compose 现在是独立插件,老版本需要单独装,新版本虽然有内置,但偶尔会因为 PATH 问题调不到。docker compose version(注意中间是空格不是横杠,docker-compose那个是老的独立版本)能出版本号就说明插件正常。4. 卡在starting把常见故障按链路排查一遍安装顺利的话,上面四步十分钟内都能过。但现实情况是,相当一部分人会卡在某个环节,而且症状高度雷同:托盘图标一直转、界面显示 Docker Desktop is starting、命令行报 cannot connect to the Docker daemon。下面按我实际遇到的频率从高到低排一遍,每一类都给完整的排查链路,你可以照着顺序试。4.1 一直转圈先看WSL状态再看服务这个是最常见的症状,也是最容易误判的。很多人一看到转圈就点Restart,重启三次无效后卸载重装,结果还是转圈,实际上问题根本不在 Docker 本身。我的排查顺序是固定的:先看 WSL,再看服务,最后才看 Docker。第一步,新开一个终端跑wsl --list --verbose。正常应该能看到至少一个docker-desktop分发,状态是 Running。如果报错说没有已安装的分发或者WSL 内核版本过低,那问题就在 WSL 层面,跟 Docker 无关。第二步,如果 WSL 列表正常但状态卡在 Installing 或者 Stopped,跑一次wsl --shutdown把所有分发停掉,然后手动启动 Docker Desktop。这个操作会清掉可能残留的僵尸进程,我大概有三成的转圈问题是被这一步解决的。第三步,检查 Windows 服务。Win R输入services.msc,找到Docker Desktop Service,看它是不是在运行。如果启动类型是手动、状态是已停止,手动启一下;如果启动报错,右键看属性里的可执行路径,通常指向安装目录下的com.docker.service,路径不对说明安装不完整,这种才需要重装。第四步,看日志。托盘图标右键 → Troubleshoot → 打开日志目录,里面com.docker.backend.exe.log是后端日志。这个文件看着吓人,但你只需要搜error和failed,通常前几行就能看到根因,比如内核版本不匹配、端口被占用、磁盘空间不足。这四步走完还定位不到,基本可以判定是组件版本问题,继续往下看。4.2 WSL2内核组件缺失的报错长什么样这个问题的报错文案很有辨识度:WSL 2 installation is incomplete或者Please update your kernel。看到这个不用犹豫,就是 WSL 的内核组件版本和 Docker Desktop 要求的不匹配。修复路径分两种。命令行能通的时候直接wsl --update,让系统自动下最新的内核和运行时,跑完wsl --shutdown再启 Docker。这条路径在大部分机器上都能解决。命令行走不通的情况,通常是系统自带的组件太老,更新器本身跑不起来。这时候去微软的官方文档页找 WSL2 内核更新包的独立安装程序,下载那个 msi,双击装上,重启系统。这个包很小,只有十几兆,装完再跑wsl --status确认默认版本是 2。还有一种更隐蔽的情况:内核更新包装上了,但系统里注册的分发还在用老的版本。表现是wsl --status一切正常,Docker 启动时仍然报内核问题。这种时候跑wsl --shutdown强制重启所有分发,再不行就把docker-desktop这个分发注销掉让它重建——注销前记得确认里面没有你需要保留的数据,注销等于删库。注意:wsl --unregister docker-desktop会把该分发连同里面的镜像和容器全部删掉,执行前想清楚。如果只是想清理空间,先做一次docker save把重要镜像导出备份。4.3 与旧版虚拟化软件抢资源的冲突这台机器上原本就装着 VMware 或者 VirtualBox 的情况非常普遍,而它们和 Hyper-V 那一套虚拟化层是天然冲突的:Hyper-V 一旦启用,就会独占 CPU 的虚拟化扩展,老的虚拟化软件拿不到,启动直接失败或者退化成极慢的软件模拟模式。判断方法很简单:装完 Docker 后,原来能正常用的虚拟机软件突然启不来了,或者报此平台不支持之类的错误,那就是这个冲突。处理思路有三条,按推荐顺序排:第一条,让 Docker 只走 WSL2 后端,不勾 Hyper-V 功能。这是最省事的方案,WSL2 用的是虚拟机平台的轻量虚拟化,和老虚拟化软件的冲突比完整 Hyper-V 小得多。实操上就是前面 2.2 节说的,安装时把 Hyper-V 那一项空着。第二条,升级那个虚拟化软件到支持共存的版本。主流的几个产品近年来都做了这方面的适配,新版本在检测到虚拟化层被占用时会自动切换到兼容模式。这个方案的代价是性能会打折扣,尤其在跑图形密集的虚拟机时。第三条,接受二选一。用 Docker 的时候把虚拟化软件的服务停掉,用完反过来。这个方案最麻烦,但如果你的虚拟化软件版本实在太老,又暂时没法升级,这就是唯一的路。还有一种容易被误判成抢资源的情况:内核隔离里的内存完整性开着,导致虚拟机平台启动失败。这个和虚拟化软件无关,表现是 Docker 装了但后端起不来,事件查看器里有虚拟化相关的报错。权衡的办法是临时关掉内存完整性验证,确认 Docker 能正常启动后再决定要不要长期保持关闭——这是个安全特性和兼容性的取舍,看你的实际使用场景。4.4 C盘被虚拟磁盘悄悄吃满这个问题不是装不上,是用着用着出事,但危害更大:某天早上打开电脑,系统盘红了,系统各种卡顿,查半天发现是一个几十 G 的 vhdx 文件。根因在于 WSL2 的磁盘是动态扩展的虚拟磁盘,你往容器里写多少东西它长多大,但删掉容器之后它不会自动缩回去。跑几次构建、拉几个大镜像,这个文件就能到几十个 G。默认位置在C:\Users\你的用户名\AppData\Local\Docker\wsl\data\ext4.vhdx(新版本可能合并进了docker-desktop分发)。处理方案有预防和补救两种。预防是在 Docker Desktop 设置的 Resources → Advanced 里,把 Disk image location 改到空间充裕的盘符上。这个操作会迁移现有数据,执行前确保目标盘有足够空间,迁移过程中别断电。补救是定期做一次压缩。最直接的办法是 Docker Desktop 自带的清理:设置页里有个 Clean / Purge data 的选项,或者用命令行docker system prune -a清掉所有不用的镜像和容器。清完之后虚拟磁盘不会自动缩,还需要在 PowerShell 里对 vhdx 做一次压缩操作。更彻底的做法是用wsl --export把分发导出成 tar,再wsl --unregister删掉,然后用wsl --import导入到别的盘——这条路能同时解决迁移和瘦身,但是操作前务必备份。症状大概率根因处理动作一直转圈不出界面WSL 分发卡死wsl --shutdown后重启报 WSL 2 installation is incomplete内核组件版本低wsl --update或装内核包报 cannot connect to daemon后端服务未启动检查服务与托盘图标原有虚拟机启不来虚拟化层被独占改用 WSL2 后端,不勾 Hyper-VC 盘空间骤减vhdx 只增不减迁移磁盘位置 定期 prune5. 装完之后的日常调优让容器别把机器拖垮跑通 hello-world 只是起点,真正决定这套环境好不好用的是接下来这几个配置。我见过太多人装完之后就不管了,结果机器越用越慢,最后归咎于Docker 太吃资源——其实只是几个默认值没调。5.1 用 .wslconfig 给虚拟机划一条内存红线WSL2 的内存策略是能用多少用多少,用完不还。默认它会拿走你物理内存的一半作为上限,但实际运行时它会尽可能占满,而且 Windows 的内存压力回收对它的约束有限。表现就是:你在容器里跑了个编译,内存飙到 8G,编译结束后这 8G 还攥在 WSL 手里不放,系统整体可用内存被压到很低,切窗口都卡。解决办法是在用户目录下建一个.wslconfig文件,给 WSL2 划一条明确的红线。路径是C:\Users\你的用户名\.wslconfig,注意文件名前面那个点,Windows 资源管理器里创建以点开头的文件会提示需要输入扩展名,直接输入.wslconfig.带个尾点就能建成。内容大概是这样:[wsl2] memory6GB processors4 swap2GB localhostForwardingtrue几个参数的含义:memory是硬上限,超过这个值 WSL 内部会触发 OOM,所以别设得太小;processors限制分配给子系统的逻辑核心数,机器是 8 核 16 线程的话给 4 到 6 比较合适,留出核心给 Windows 本身;swap是交换空间,给一点能缓解突发的内存峰值,但别指望它提升性能;localhostForwarding让容器映射的端口能直接通过 localhost 访问,这个默认是开的,写出来只是为了明确。写完之后必须执行wsl --shutdown让配置生效,然后重启 Docker Desktop。这里有个坑:很多人改完文件直接重启 Docker,发现内存上限没变,就是因为没关掉 WSL 实例,配置只在实例重新创建时读取一次。值不值得调?我的经验是,16G 内存的机器上调这一下,感知非常明显,尤其是同时开着浏览器一堆标签页的时候。32G 以上的机器,默认值通常够用,调不调都行。5.2 没有网速优势时的镜像搬运方案拉取镜像慢是所有人都遇到过的问题,尤其是在需要拉几个 G 的基础镜像时,那个进度条能磨掉半小时。这里我不讨论各种加速配置,只说一个最朴素但最靠谱的方案:离线搬运。原理很简单,Docker 的镜像可以完整地导出成一个 tar 文件,在另一台机器上再导入,中间不依赖网络。命令只有两条:# 在有镜像的机器上导出,可以一次导出多个 docker save -o myapp.tar myapp:1.0 nginx:alpine # 在目标机器上导入 docker load -i myapp.tar这套方案特别适合几个场景:一是公司内网机器完全没外网,只能靠 U 盘或者内部文件服务器搬;二是团队里几个人要跑同一套环境,一个人拉好导出,其他人分发,省得每个人都去拉一遍;三是做交付时把镜像和代码一起打包,对方拿到就能跑。实操上有几个细节要注意。docker save导出的 tar 是不压缩的,体积和镜像本身一样大,传输前建议用 gzip 压一下,docker save myapp:1.0 | gzip myapp.tar.gz,导入时反过来gunzip -c myapp.tar.gz | docker load。另外,导出时把镜像的完整标签带上,导入之后标签不会丢,但如果导出时用的是镜像 ID,导入后就变成none:none了,得手动 retag,很麻烦。还有一个更省空间的思路:如果目标机器只是要跑,不需要构建过程,可以考虑把整个镜像用docker export导出成文件系统的 tar,体积会小很多,但代价是丢失了镜像的分层信息和元数据,导入后是个扁平的文件系统,不能再当作镜像用。这个方案适合做静态交付,不适合日常开发。5.3 挂载目录选择与文件读写性能这一条是我踩过最深的坑,值得单独拿出来说。很多人在 WSL2 后端下把项目代码放在 Windows 的 D 盘,然后-v D:\project:/app挂进容器,结果发现容器里读文件慢得离谱,跑个前端构建要等好几分钟,还以为是 CPU 不够。根因是跨文件系统的 IO。WSL2 访问 Windows 文件系统(挂载在/mnt/d这类路径下)时,每一次文件操作都要经过一层协议转换,小文件密集读写场景下这个开销被放大几十倍。反过来,如果你把代码放在 WSL 自己的文件系统里(比如\\wsl$\Ubuntu\home\user\project),容器访问就是原生速度。所以我的建议很明确:项目代码放 WSL 文件系统里,用 VS Code 的 Remote 功能连进去编辑。这样编辑器、终端、容器三者看到的都是同一份文件,读写全在原生文件系统内,热重载的 inotify 事件也能正常传递——这一条在挂载 Windows 目录时经常失效,表现为改了代码容器里没反应,得手动重启。不得不挂在 Windows 目录的情况也有,比如代码要和 Windows 上的其他工具链共享。这种时候能做的优化是:把node_modules、target、dist这类高频读写的目录用匿名卷单独挂出来,避免它们走跨系统 IO。命令上就是多加一个-v /app/node_modules,让这部分数据留在容器自己的文件系统里,只把源码目录从外面映射进来。这个技巧能救回大半的性能。6. 卸载与重装把残留清干净才算真的卸了最后说卸载,因为重装是排错的最后手段,而重装失败最常见的原因是没卸干净。控制面板里点卸载只是第一步,数据目录、WSL 分发、注册表项都还在,下次装上来读到的还是旧的坏配置。6.1 标准卸载顺序顺序很重要,反了会留下删不掉的锁文件。第一步,退出 Docker Desktop,托盘图标右键选 Quit。别直接任务管理器结束进程,那样服务可能还在跑。第二步,控制面板 → 程序和功能 → 找到 Docker Desktop → 卸载。卸载程序会问你要不要保留镜像数据,如果你就是要清干净重装,选不保留。第三步,注销 WSL 分发。命令行跑wsl --list看看还有没有docker-desktop相关的条目,有的话wsl --unregister docker-desktop。老版本还会有一个docker-desktop-data,一并注销。这一步做完,那个几十 G 的 vhdx 文件才会真正被释放。很多人卸载完发现 C 盘空间没回来,就是漏了这一步。第四步,手工删残留目录。三个位置:%APPDATA%\Docker、%LOCALAPPDATA%\Docker、%USERPROFILE%\.docker。第一个是配置,第二个是数据和日志,第三个是客户端的配置和凭证。删之前如果config.json里有你配过的私有仓库凭证,先备份出来。6.2 重装前值得多看一眼的两个地方重装之前,有两个东西值得确认一下,能省掉一次白装。一个是 WSL 的状态。跑wsl --status和wsl --list --verbose,确认默认版本是 2 且没有残留的坏分发。如果列表里有状态异常的分发,先注销掉。这个检查能避免重装后依然卡在同一个地方。另一个是磁盘空间和权限。装之前确认系统盘有 20G 以上空余,以及你的用户账户对%LOCALAPPDATA%有完整写权限——用受限账户或者域账户的机器上,这一条偶尔会出问题,表现是装完启动时报无法创建数据目录。有疑问的话,用管理员身份跑一次安装程序,装完再用普通账户启动。我个人在实际操作中的体会是,Win10 上装 Docker 这件事,难点从来不在 Docker 本身,而在于它踩在 Windows 虚拟化栈、WSL 子系统、磁盘布局这几个东西的交界处。把前置条件(版本、虚拟化、系统功能)对齐,把后端选型(WSL2)定死,把两个日常配置(.wslconfig 限内存、项目目录放 WSL 文件系统)做对,后面基本就是无感的。真正会反复折腾人的,是那些装的时候没问题、用两周之后突然卡住的场景,而它们的根因九成能在磁盘空间和 WSL 实例状态这两个地方找到——先跑wsl --shutdown,再清一次docker system prune,能解决你遇到的绝大部分玄学问题。