企业官网建设流程全解析

上周帮人调一个 Docker 问题，现象很典型：Docker Desktop 装好了，界面也起来了，但命令行docker run hello-world半天拉不动，最后直接报错。远程看了一眼，问题根本不在 Docker 本身，而在底层的 WSL2 压根没跑起来。这种问题在 Windows 上太常见了——很多人以为装 Docker 就是双击安装包然后一路下一步，却忽略了 Windows 上跑 Docker，其实跑的是一个藏在子系统里的轻量 Linux 环境。

这篇文章我打算把 Windows 上部署 Docker 的完整链路讲一遍：先讲清楚为什么 Windows 上跑 Docker 要经过 WSL2 这一层，再按顺序把环境准备、Docker Desktop 安装、镜像源配置、第一个容器跑通讲完整，最后列出我在实际使用中经常遇到的故障排查经验。不管你是刚接触容器开发的新手，还是已经在 Windows 上折腾了一阵子但没搞懂底层逻辑的开发者，这份内容应该都能对得上号。

1. 先搞清楚一件事：Windows 上跑的 Docker，其实不是“原装”的

Docker 本身是 Linux 的技术。容器之所以能做到启动快、隔离干净，靠的是 Linux 内核里的命名空间（namespace）和控制组（cgroup），这两个机制把进程划进独立的沙箱，但虚拟化开销又远小于整台虚拟机。Windows 内核没有这套机制，所以想在 Windows 上跑常见的 Linux 容器，必须先叠一层虚拟化技术。

这句话很多人不爱听，但理解了它，后面几乎所有排错都能想通。Windows 上的 Docker 有两种模式：Windows 容器和 Linux 容器。Windows 容器直接跑在 Windows 之上，听起来很顺，但官方镜像、第三方镜像绝大多数都是 Linux 架构，日常开发根本用不上；Linux 容器才是主流，而 Linux 容器在 Windows 上必须通过虚拟层运行。

很多人会问：那直接装个虚拟机，在里面装 Linux，然后跑 Docker 不就行了？能行，但这是个巨大的坑。早期 Docker Toolbox 时代就是这么干的，体验很差，稍后我会讲到。现在 Docker 官方走的路是 WSL2。

WSL2 严格来说依然是一个轻量虚拟机，但它和传统 Hyper-V 虚拟机不是一回事。传统 Hyper-V 虚拟机会为每个虚拟机分配固定的 CPU 和内存，启动动辄几十秒；WSL2 是一个带动态内存分配的轻量化虚拟机，没有完整的 BIOS 启动流程，秒级启动，内存按需分配。别管那些底层细节，记住一句话：WSL2 是 Docker 在 Windows 上最理想的底座。

那为什么有些人不选 Hyper-V 后端？Docker Desktop 早期确实可以用 Hyper-V 后端，但它有两个很致命的问题：第一，Windows 10 家庭版默认不带 Hyper-V，装都装不上；第二，Hyper-V 后端启动的虚拟机资源占用非常固定，8GB 内存的笔记本分给它 4GB，留给宿主系统的体验就很糟糕。WSL2 出现之后，Docker Desktop 很快就默认切到 WSL2 后端，现在基本不需要考虑 Hyper-V 了。

这里还有一个常见的历史遗留坑：很多年前玩 Docker 的人是通过 Docker Toolbox 入门的，那套方案在 VirtualBox 里跑一个虚拟机，所有容器都在这台虚拟机里跑，然后通过端口转发把服务暴露给宿主机。体验不太行，启动慢、端口映射容易错乱、磁盘 IO 差，而且 VirtualBox 和后来的 Hyper-V/WSL2 还有冲突。如果你电脑上残留着旧版 Docker Toolbox 相关程序，先卸载干净再继续。

我把三种方案的差别放在一个表格里：

结论很直接：如果你用的是新版 Windows 10/11，并且没有非要自己管理 Hyper-V 虚拟机的特殊需求，直接 WSL2 就完事了。接下来要讲的环境准备，全部围绕 WSL2 展开。

2. 部署前的环境盘点：确认版本、打开虚拟化、升级 WSL2

在双击安装包之前，先把环境检查一遍，能省出一堆莫名其妙的踩坑时间。这一步很多人当成“再次确认”然后跳过了，结果后面查了半天才明白问题出在哪儿。所以我建议每一条都照着看一眼。

2.1 操作系统版本

WSL2 对 Windows 版本有硬性要求。Windows 10 64 位系统必须是 Build 19041 或更高，也就是 2004 版本之后；Windows 11 全版本都行；Windows Server 2019 及以上也可以。如果你的系统还停留在 Windows 10 1909 或更早，先查一下 Windows 更新，把系统补丁打满再说。另外必须说明，这里聊的是 Linux 容器，如果你的系统是 Windows 7/8 这种老古董，官方方案已经没有了，不建议继续折腾，直接换新系统或者换台机器更现实。

版本支持情况我整理了一个对照表，方便你直接对号入座。这里说的是 WSL2 支持情况，不是 Docker Desktop 的安装支持——只要 WSL2 能跑起来，Docker Desktop 基本就能跑：

2.2 检查 CPU 虚拟化是否开启

没有虚拟化支持，WSL2 直接没法用。打开任务管理器，性能标签页里选 CPU，右下角有一项“虚拟化: 已启用”或“已禁用”。如果你更习惯命令行，可以打开 CMD 运行systeminfo，在输出里找“Hyper-V 要求”这一段：

Hyper-V 要求: VM 监视器模式扩展: 是 已启用基于虚拟化的安全性: 是 固件中已启用虚拟化: 是 二级地址转换: 是 数据执行保护: 是

只要“固件中已启用虚拟化”显示“否”，就得进主板 BIOS/UEFI 把它打开。不同品牌进入方式不一样，开机时按 Del 或 F2 最常见，进去找 Intel Virtualization Technology（VT-x）或者 SVM Mode（AMD），改成 Enabled 保存重启。做完这一步，系统里才会多出虚拟化扩展。

如果你是在虚拟机的 Windows 里装 Docker，那还要在虚拟机软件设置中开启“嵌套虚拟化”——通俗说就是允许虚拟机内部再开一层虚拟化。VMware 和 VirtualBox 的开关位置不一样，但基本都在 CPU/处理器选项里。这点极其隐蔽，很多人折腾两三天最后发现是宿主机的嵌套虚拟化没开。

2.3 开启 WSL 与虚拟机平台功能

以管理员身份打开 PowerShell 或 CMD，依次执行这两条命令：

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

执行完系统会提示重启，该重启就重启，别硬熬。重启之后回来继续下面的 WSL 内核更新。

2.4 更新 WSL 内核并安装一个 Linux 发行版

Windows 10 2004 之后，微软把 WSL 内核从商店或系统更新里分发。在管理员 PowerShell 里执行：

wsl --update

可以把它更新到最新。如果提示找不到更新，就去微软官方下载中心搜一下对应的 WSL 更新安装包，装完再执行一次wsl --version确认。

然后安装 Linux 发行版。推荐在微软商店里装 Ubuntu 22.04 LTS，或者直接用命令行：

wsl --install -d Ubuntu

这会自动下载并安装 Ubuntu。第一次进入 Ubuntu 时会让你创建一个 Linux 用户名和密码，注意这个用户和 Windows 用户不是同一个，它会成为你在容器里操作文件时的身份，密码别忘了。之后在 CMD 里执行：

wsl -l -v

如果看到 Ubuntu 那一行的 VERSION 是 2，说明 WSL2 已经就绪。如果显示是 1，用命令切到 2：

wsl --set-version Ubuntu 2

切换需要几分钟，中间别关终端。到这一步，WSL2 环境就准备好了，接下来可以装 Docker Desktop。很多人在这一步偷懒跳过，但这里的每一项几乎决定了后面所有步骤能不能顺畅，多花十分钟非常值。

3. 安装 Docker Desktop 与镜像源配置：别只在“下一步”里打转

WSL2 准备好之后，Docker Desktop 的安装反而是最简单的一部分，但依然有几个选择会影响后续体验：安装时的后端勾选、镜像加速、存储位置、资源配额。这四个点不处理，后面早晚要回头再折腾。

3.1 下载安装包与首次安装

先去 Docker 官网下载 Docker Desktop for Windows 安装包，尽量别从第三方下载站拿，毕竟这个软件带系统权限，来历不明的版本有隐患。安装包大概几百 MB，双击之后会问用 WSL 2 还是 Hyper-V。新版默认就是 WSL 2 后端，保持勾选即可。

接下来的安装过程基本就是“下一步”，中间会装一些配套组件，比如 Windows 集成、路径共享等。装完它会提示登录 Docker 账号，实际上不登录也能正常用命令行，只是 Desktop 界面里某些功能要登录。不想注册就跳过，只在命令行里用完全没问题。

3.2 首次启动与那个“Docker Engine starting”提示

第一次双击 Docker Desktop 图标后，它会启动后台引擎，界面上鲸鱼图标转圈，写着 Docker Engine starting。第一次会比较久，因为它要把docker-desktop和docker-desktop-data两个 WSL 发行版拉到本地并启动。如果超过 5 分钟还在转，一般不是慢，是出问题了——最常见的根因就是第二节里 WSL2 没配好。排查思路是执行wsl -l -v，看那两个 docker 开头的发行版是否处于 Running 状态；如果是 Stopped，执行wsl --shutdown让所有 WSL 发行版重启，再重新打开 Docker Desktop；如果根本不存在那两个发行版，多半是安装过程有损坏，卸载重装一次。

还有一个容易忽略的点：如果你的 Windows 用户名包含中文，某些老版本 Docker Desktop 在创建 WSL 发行版时可能出现路径问题。新版其实已经兼容了，但如果你的用户名是“张三”这种，遇到奇怪的路径错误可以从这里排查，最粗暴的避免方式是使用纯英文的 Windows 账户。

3.3 镜像源配置：让 docker pull 不再慢到怀疑人生

Docker 默认从 Docker Hub 拉镜像，国内网络环境直连非常慢，甚至超时。解决办法是配置 registry mirror。在 Docker Desktop 界面右上角齿轮进入 Settings，左侧选 Docker Engine，右边是 JSON 配置窗口，默认长这样：

{ "builder": { "gc": { "enabled": true, "defaultKeepStorage": "20GB" } }, "experimental": false }

把registry-mirrors加进去：

{ "builder": { "gc": { "enabled": true, "defaultKeepStorage": "20GB" } }, "experimental": false, "registry-mirrors": ["https://docker.mirrors.ustc.edu.cn"] }

想多加几个就往数组里继续加字符串。保存后 Docker Desktop 会自动重启引擎，然后在 CMD 里执行：

docker info

看输出里的Registry Mirrors字段，出现刚配置的地址就说明生效了。

这里多说一句：镜像加速器本质上是 Docker Hub 的代理缓存，它只能加速本身在 Docker Hub 可公开下载的镜像。如果某个冷门镜像在加速器上还没缓存，第一次拉可能依然会回源请求，所以某些镜像依旧慢，这很正常。选加速源时，我建议优先用知名高校或云厂商公开提供的地址，不要用来源不明的“加速器项目”——镜像内容理论上会被对方完整读到，安全上赌不起。

3.4 存储位置与资源配额：提前给 C 盘松松绑

Docker 的镜像和容器默认存放在C:\Users\<你的用户名>\AppData\Local\Docker\wsl下的虚拟磁盘文件里。用 WSL2 后端时，这个虚拟磁盘会被 Docker 一点点撑大，如果 C 盘本身不宽裕，装几个大镜像动辄几十 GB。建议在 Docker Desktop Settings 的 Resources -> Advanced 里找到 Disk image location，把它改到别的分区，比如 D 盘的 docker 目录。这个操作是整体迁移，比较慢，但一步到位。

同时在这个页面里可以限制 CPU 和内存。我的建议是：16GB 内存的机器给 Docker 分配 4GB 就够日常开发了，CPU 给 2 到 4 核，Swap 给 1GB 上下。给得太少，容器集群容易 OOM；给得太多，宿主机自己卡顿。这是动态平衡，参数设完可以观察几天再微调。

到这一步，Docker Desktop 已经能顺利用了。但我还是建议先别急着上生产容器，花两分钟跑通最基础的示例，确认整条链路没问题。

4. 跑通第一个容器：hello-world 只是起点，拉一个 Nginx 才算入门

装完 Docker Desktop，很多人会直接搜教程跑 hello-world，结果在终端敲了docker run hello-world，等半天没反应，开始怀疑人生。原因基本出在两个地方：镜像源没配好，或者后台引擎还没起来。先用docker version看 Client 和 Server 两块信息。Server 那一块的 Engine 版本正常，说明 daemon 没问题；Server 报 error，那九成是 Docker Desktop 的引擎状态没就绪。

4.1 从 hello-world 验证最小链路

一切正常时，执行：

docker run hello-world

输出里会有一大段文字，意思是本地没有这个镜像，于是从 Docker Hub 拉取了一个 hello-world 镜像，然后运行它并打印提示。别看它简单，这条命令其实验证了四个环节：镜像拉取、镜像存储、容器创建、容器运行。任何一个环节出问题，输出都会卡住或报错。到这一步，你的 Windows + Docker 基础链路已经通了。

4.2 跑一个真正的服务：Nginx

hello-world 只是验证，要真正有“我在用 Docker”的感觉，最好跑一个 Nginx：

docker run -d --name web-test -p 8080:80 nginx:alpine

参数拆开说：-d表示后台运行，--name给容器起名字，-p 8080:80代表把宿主机的 8080 端口映射到容器内部的 80 端口，nginx:alpine是镜像名和标签。Nginx 镜像默认监听 80 端口，所以浏览器访问 http://localhost:8080 就能看到欢迎页。如果访问不上，先docker ps看容器是不是 Exited 状态，再用docker logs web-test看容器日志。

这种端口映射的方式，本质上是把容器看成一个黑盒，外部只通过端口和它通信。在 Windows 上，这个映射由 Docker Desktop 的虚拟化层自动完成，你不需要关心它怎么转发到 WSL 里的，只需要分清宿主机端口和容器端口这个方向。

4.3 进入容器、看日志、停启容器

跑起来之后，运维命令顺手练一遍：

docker ps docker logs web-test docker exec -it web-test sh docker stop web-test docker start web-test docker rm web-test

docker exec -it web-test sh是进入容器的 shell。因为nginx:alpine镜像很精简，里面只有 sh 没有 bash。你可以在容器里看看/usr/share/nginx/html目录，会深刻理解“镜像其实就是一套文件系统加启动命令”。

这里特别想提醒一点：容器是可丢弃的运行环境，不要养成“进容器改东西”的习惯。容器一删，里面改的东西全没了。要在代码层面控制行为，要么写 Dockerfile、改配置文件重新构建镜像，要么用数据卷把配置文件挂载进容器。这个习惯在 Windows 上更容易建立，因为操作路径不比 Linux 那么顺手，反而会逼着你走正确流程。

4.4 从单容器到组合服务：Docker Compose 一把梭

单个容器玩熟之后，最有价值的一步就是学会 Docker Compose。想象一下：以前想在本机搭一套 WordPress 开发环境，要装 PHP、配 MySQL、装 Nginx、处理版本冲突，一套下来大半天；用 Compose 只需要一个 yaml 文件，敲一条命令等镜像拉完，服务直接全部起来。

新建一个目录，比如wp-dev，在里面放docker-compose.yml：

services: db: image: mysql:8.0 command: --default-authentication-plugin=mysql_native_password restart: always environment: MYSQL_ROOT_PASSWORD: rootpass MYSQL_DATABASE: wordpress MYSQL_USER: wpuser MYSQL_PASSWORD: wppass volumes: - db_data:/var/lib/mysql wordpress: depends_on: - db image: wordpress:latest restart: always ports: - "8080:80" environment: WORDPRESS_DB_HOST: db:3306 WORDPRESS_DB_USER: wpuser WORDPRESS_DB_PASSWORD: wppass WORDPRESS_DB_NAME: wordpress volumes: - wp_data:/var/www/html volumes: db_data: wp_data:

然后在目录里执行：

docker compose up -d

稍等一会儿，浏览器访问 localhost:8080 就能看到 WordPress 安装界面，数据库配置已经全部自动完成。数据库和 WordPress 的数据都存在命名卷里，以后docker compose down -v会连数据卷一起删，日常开发不想全删就别加-v。

这套组合给 Windows 开发带来的价值非常大：你不再需要在一台 Windows 机器上装各种服务端软件，不必担心服务互相抢占端口、环境变量互相污染。所有中间件都在容器里，彼此隔离，共享一套内核。而且docker-compose.yml是对环境配置的完整描述，放进版本仓库，换电脑时 clone 下来up一下，开发环境就回来了。

5. 踩坑实录：Windows 下 Docker 最常见故障的完整排查链路

这章算是全文的精华。我不是要把所有人按头教一遍，而是把过去一年多处理过的同类问题汇总一下。每个问题都先描述现象，再给排查链路，尽量做到你可以照着复现排查思路。

5.1 WSL2 起不来：错误码 0x80370102

现象：在 CMD 或 PowerShell 里执行wsl或wsl -l -v，立刻弹错误“WSL2 安装不完整”或错误码 0x80370102。这个错误基本可以断定是 CPU 虚拟化没开，或者嵌套虚拟化没开，系统根本创建不了 WSL2 虚拟机。

排查链路：

• 打开任务管理器，看 CPU 的“虚拟化”是否为“已启用”。
• 执行systeminfo，看“固件中已启用虚拟化”那行。
• 确认有没有装过 VirtualBox、VMware，它们有时和 WSL2 的虚拟化层抢占资源，先把它们虚拟化/加速相关的设置关掉。
• 最后检查你是否在一个虚拟机里面——如果是，去虚拟化平台的控制台开启嵌套虚拟化，重启 Windows 后再试。

修复：进 BIOS 开启 VT-x/SVM，或在虚拟机设置中开启嵌套虚拟化，重启后问题基本消失。

5.2 Docker Desktop 一直转圈，Docker Engine starting 没完没了

现象：Docker Desktop 每次启动都卡在 Docker Engine starting。完整的排查链路是这样：

• 先执行wsl -l -v，重点看docker-desktop和docker-desktop-data的 STATE 列。
• 如果这两个发行版压根不存在，大概率安装文件或过程损坏，先卸载 Docker Desktop 再重装。
• 如果存在但 STATE 是 Stopped，执行wsl --shutdown停掉所有发行版，等十几秒再打开 Docker Desktop。
• 如果它们显示 Running，但引擎还是起不来，打开 Docker Desktop 的日志菜单，看日志目录里最近的报错，一般会指向 WSL 组件或镜像源，把这两个点再查一遍。
• 如果这个状态出现在你刚改完 Docker Engine 的 JSON 配置之后，那多半是 JSON 写错，把配置还原再重启。

经验谈：Docker Desktop 转圈时别急着杀进程重开，越频繁杀越容易留下残留状态。给足两三分钟，如果还不行，再按上面的链路分析。

5.3 vmmem 进程吃内存吃到怀疑人生

现象：装完 Docker 后，任务管理器里总会有一个vmmem进程，可能占 3GB、5GB 甚至更多内存。这不是病毒，是 WSL2 的运行进程。

原因：WSL2 在空闲时会拿系统内存做文件缓存，它认为把内存“借”出去更高效，但 Windows 宿主机上的我们并不总是这么想。解决办法是创建%UserProfile%\.wslconfig文件，写入：

[wsl2] memory=4GB processors=4 swap=0 localhostForwarding=true

然后执行wsl --shutdown，再重新打开 Docker Desktop，限制就生效了。注意：这个文件影响的是所有 WSL2 发行版，不是 Docker 专属，所以内存别设太小，否则其他 WSL 发行版也会跟着受限制。我自己的 16GB 笔记本就设成 4GB，日常跑两三个容器完全够。

5.4 容器起来了，但浏览器死活访问不到端口

现象：docker ps里容器显示 Up，日志也没报错，但浏览器访问 http://localhost:8080 一直拒绝连接。

排查链路：

• 先确认映射参数：docker port web-test，它会直接列出宿主机端口和容器端口。
• 如果宿主机端口不是 8080，或映射没生效，删掉容器用正确参数重新创建。容器端口映射不是改配置就能立即生效的，必须重建容器。
• 然后检查 8080 是否被本机其他程序占用：netstat -ano | findstr :8080。如果有一个 PID 在 LISTENING，说明 Windows 上已有程序占了这个端口，那就把容器端口换一个，比如-p 8081:80。
• 最后看 Windows 防火墙。开发机最省事是临时放行 Docker Desktop 对应的流量规则，生产环境另说。
• 还有一个隐蔽点：如果容器内部的服务监听的是 127.0.0.1 而不是 0.0.0.0，端口转发也可能有奇怪表现，排查时也去看一眼进程的启动参数。

这类问题多数不是 Docker 本身的问题，而是 Windows 侧环境或端口被占的细节。

5.5 挂载 Windows 目录后，代码改了半天容器里还是旧内容

现象：把D:\myproject挂载进容器当应用目录，宿主机修改文件后，容器里看到的还是旧版本，或者文件操作速度极慢。

原因：WSL2 对跨文件系统访问，也就是 Windows 盘符和 WSL 内部文件系统之间的来回读写，本身性能就偏低，文件监听机制也不够实时。这是 WSL2 当前架构上的物理限制。

解决办法很现实：开发项目尽量放在 WSL 自己的文件系统里，比如/home/你的用户名/project，然后在 Docker Desktop 的 File sharing 设置中把项目对应盘符加入共享列表。挂载路径时，Windows 风格路径和 WSL 风格路径容易混，比如在 Windows 上的 CMD 里挂载常见写法是-v /d/myproject:/app，在 WSL 里则是/mnt/d/myproject。如果实在要用 Windows 盘符挂载，把只读挂载用于静态资源，需要频繁读写的目录留在 WSL 内部。

这个坑踩过的人都懂，属于 Windows Docker 的长期痛点之一。好在现在越来越多人直接用 VS Code 的 Remote-WSL 插件，把整个项目放在 WSL 里跑，从编辑器到容器到宿主机形成一条完整链路，体验顺畅很多。

5.6 Docker Desktop 退出了，WSL 里还有一堆进程

现象：Docker Desktop 图标关掉之后，wsl -l -v里 docker-desktop 仍然显示 Running，后台还挂着大量进程。有人觉得这是 Bug，其实设计如此——Docker Desktop 关闭只是关了界面，容器引擎不一定跟着停。

如果想彻底释放资源，执行wsl --shutdown能停掉所有发行版，但这会把你自己的 Ubuntu 也一起关掉，注意保存好 WSL 里没写完的内容。日常开发中，频繁开关 Docker 引擎反而会把 WSL 缓存搞得很乱。我一般只在长时间不开发时才把它关掉，短暂离开就让容器开着，内存限制配好就不会太心疼。

6. 从“能跑”到“好用”：我的一些建议

不重复前文，这里补几条我认为最终从“能跑”走到“好用”的人，都会主动做的配置和习惯。

6.1 让 .wslconfig 长期稳定运行

除了限制内存，.wslconfig里还可以设置实验性的自动内存回收，比如autoMemoryReclaim=gradual，适当配置能缓解内存回收不及时的问题。但这个配置在不同 Windows 版本上行为略有差异，改完多观察一天。这类配置本质上是用微软公开的文档做基础，再按自己机器状态调，不要照搬别人的数值，因为每个人的内存和项目复杂度都不一样。

6.2 每周删一批没有用的镜像和缓存

在 Windows 上跑 Docker，镜像存储直接占满你指定的分区。常用命令：

docker system df docker system prune -a

docker system prune -a会清理所有未被容器使用的镜像、停止的容器、悬空数据卷和构建缓存，一键释放几十 GB 的情况很常见。但执行前用docker ps -a确认没有你想保留但没运行的容器，否则旧容器没了，有些想留着的日志也就一起没了。我习惯先docker system df看当前各块占用，再决定要不要 prune。

6.3 镜像存储位置迁移到非系统盘

前面提过 Docker Desktop 图形界面有迁移操作。但有时候迁移会因文件锁失败，或者你想直接手工操作，可以用 WSL 导出/导入的方式。把docker-desktop-data发行版导出成 tar，再导入到新位置。示意流程：

wsl --shutdown wsl --export docker-desktop-data D:\docker-backup\docker-desktop-data.tar wsl --unregister docker-desktop-data wsl --import docker-desktop-data D:\docker\data D:\docker-backup\docker-desktop-data.tar

导出的文件可能非常大，导入到新位置也需要一段时间。如果目标盘空间不足，先别开始。这种方式比图形界面迁移更彻底，但也更容易把 Docker Desktop 弄乱，所以迁移前我会先对原来的 WSL 目录做备份。如果没把握，优先用 Docker Desktop 自带的 Disk image location 选项，它对各种边界情况的处理更稳。

6.4 安全底线：镜像和容器的权限原则

Windows 上的 Docker 与系统网络集成度高，更要小心来源不明的镜像。我只从 Docker Hub 官方账号或知名项目拉镜像，尽量用library/官方镜像、带明确版本号的 tag；不用 root 权限跑未知镜像；不对容器随便加--privileged。有人为了方便把 Docker socket 挂进容器，这等于把 Docker 宿主机的整个控制权交给容器，在不可信镜像上这是极其危险的，最好永远不要这么干。

6.5 我目前在 Windows 上最常起的容器组合

讲这么多原理，最后说点实际的。我自己这台 Windows 开发机上，Docker 里最常跑的是这么几组：一个 MySQL 容器，端口 3306 映射，数据卷持久化；一个 Redis 容器，端口 6379 映射，只做本地缓存，没配持久化；一个 Nginx 容器做反向代理，转发到本地几个自研服务；偶尔再起 Postgres、RabbitMQ 和一些工具镜像。这组合几乎覆盖了我日常的全部开发依赖。

每次重装系统或者换新电脑，最惦记的其实不是那些绿色软件，而是哪几份 docker-compose.yml。把文件往版本仓库一放，新机器上装好 Docker，进去执行docker compose up -d，开发环境基本上几十秒内就重建完。从最开始只是虚拟机上跑着玩，到后面真正成为开发流程不可分割的一部分，Windows 上的 Docker 给我的感觉，就是把一堆之前要在系统里反复折腾的基础设施，变成了可以被文本描述、被命令行调用的普通资源。配置源、资源配额、数据卷、compose 文件，这些细节提前弄明白，后面稳定用几年都不会有问题。