Windows 原生跑 Linux 容器：WSL 2 + Docker Desktop 完整实战指南

Windows 上跑 Linux 容器，以前的办法绕远路：先装 VMware 或 VirtualBox，建一台 Ubuntu 虚拟机，再在虚拟机里装 Docker，容器和 Windows 之间的文件、端口、剪贴板全靠手动打通。这套流程不是不行，而是太重。WSL 2 落地之后，情况已经变了：Windows 自带一个真正的 Linux 内核，Docker Desktop 把后端切到 WSL 2，Linux 容器就相当于直接跑在 Windows 主机上，不需要你手动维护虚拟机。

这篇文章就围绕“Windows 原生跑 Linux 容器”这条主线，把环境准备、WSL 2 开启、Docker Desktop 部署、Nginx/Redis 容器实测、Compose 多容器编排、Docker 接口与批量任务、资源占用观察和常见坑位都过一遍。文中的命令以 Windows 11 和较新的 Windows 10 为例，老版本系统请先确认版本再动手。如果你只是为了本地调试中间件、跑一套可复现的开发环境，或者想学 Linux 容器但不想装双系统，这篇可以直接收藏。

先说结论：这个方案的核心不是“Windows 模拟 Linux”，而是 WSL 2 为 Windows 提供了一个真实 Linux 内核，容器引擎跑在这个内核之上，因此容器里的行为、动态链接库、系统调用和 Linux 服务器基本一致。下面从能力速览开始逐步展开。

1. 核心能力速览

这里说的“原生”，指的是日常操作体验上的原生：你不需要自己创建虚拟机、不需要在虚拟机里配置网络和共享目录，WSL 2 和 Docker Desktop 把这些细节封装掉了。但它本质上仍是轻量级虚拟化，不是 Linux 直接跑在裸机上。

2. 适用场景与使用边界

这个方案最适合三类人：

• 后端开发：本地起 MySQL、Redis、Elasticsearch、Nginx 等中间件，跑完就删，不污染 Windows 环境。
• 需要复现环境的人：用 Compose 把依赖服务、版本、端口、环境变量写进一个文件，换机器也能跑。
• 学习容器和 Linux 的人：在不折腾双系统的情况下，接触真实的 Linux 系统调用和文件系统。

能解决的核心问题是环境不一致：同一个 Compose 文件在 Windows 和 CI 机器上行为一致，中间件版本固定，团队协作时不用再互相问“你本地装的是哪个版本”。

边界也很明显：

• WSL 2 是轻量级虚拟机，不是生产级虚拟化平台，内核模块、特殊驱动、硬件直通类操作受限。
• 一台 Windows 主机同一时间只能用一个 Docker 引擎类型。Docker Desktop 里可以在 Linux 容器和 Windows 容器之间切换，但两者不能同时运行。
• Windows 容器需要 Windows 容器基础镜像，和 Linux 容器是两条完全不同的技术路线，别混用。
• 容器里的系统调用兼容性已经很好，但涉及设备驱动、实时性要求较高的场景，还是要放在真正的 Linux 环境验证。

合规方面提醒一句：从公共仓库拉取的镜像要注意软件许可，企业团队使用 Docker Desktop 前，要按照 Docker 当前的订阅政策确认是否在免费范围内，拿不准就去查官方许可说明。涉及内部代码、数据的镜像不要推到公共仓库，先做好镜像扫描和访问控制。

3. 环境准备与前置条件

3.1 检查系统版本与虚拟化支持

先确认 Windows 版本，按 Win + R 输入 winver 回车，查看版本号。WSL 2 的完整支持从 Windows 10 2004（build 19041）开始，Windows 11 直接可用。

再确认 CPU 虚拟化已开启。打开任务管理器，切换到“性能”页，选中 CPU，看右下角“虚拟化”是否为“已启用”。如果显示“已禁用”，需要进 BIOS 开启 Intel VT-x 或 AMD-V。注意，如果 Windows 本身运行在虚拟机里，还需要宿主机开启嵌套虚拟化。

powershell复制# 查看系统简要信息
systeminfo | Select-String "Hyper-V|虚拟化"

这一步容易被忽略，但绝大多数“WSL 2 装不上”“Docker Desktop 起不来”的问题都出在虚拟化未开启。

3.2 启用 WSL 2 所需功能

用管理员身份打开 PowerShell，依次执行两条命令启用“适用于 Linux 的 Windows 子系统”和“虚拟机平台”：

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

执行完成后重启系统。较新的 Windows 11 可以直接执行：

powershell复制wsl --install

这个命令会自动启用所需功能并安装默认的 WSL 发行版。Windows 10 较旧版本如果提示缺少 WSL 2 内核更新，需要从微软官网下载 WSL2 Linux 内核更新包并双击安装。安装完成后把默认版本设置为 WSL 2：

powershell复制wsl --set-default-version 2
wsl --install -d Ubuntu

这里再提醒一个磁盘问题：WSL 2 使用动态扩展的虚拟磁盘（vhdx），Docker 镜像和容器数据都会占用磁盘。建议给 C 盘留出至少 20GB 空间，如果 C 盘紧张，后续可以通过迁移 WSL 发行版到其他分区解决。

4. 安装部署与启动方式

4.1 安装 Docker Desktop 并切换 WSL 2 后端

从 Docker 官网下载 Docker Desktop 安装包，双击安装。安装时有一步会让你选择使用 Windows 容器还是 Linux 容器，这里直接选 Linux 容器，后端保持默认的 WSL 2 即可。如果你已经安装了旧版本，去设置里确认：

• Settings -> General -> Use the WSL 2 based engine，勾选。
• Settings -> Resources -> WSL Integration，打开你想要的发行版集成开关。

从 Docker Desktop 的架构看，WSL 2 后端启动后，Docker 引擎实际运行在 WSL 2 的发行版内部，Windows 上的 Docker CLI 通过命名管道与引擎通信。对外表现就是：你打开 PowerShell 敲 docker 命令，行为和 Linux 上几乎一样。

4.2 命令行验证服务状态

安装完成后，重新打开 PowerShell，检查 WSL 发行版状态和 Docker 引擎信息：

powershell复制# 查看 WSL 发行版与版本
wsl -l -v

正常情况下会看到类似输出：Ubuntu 发行版的 VERSION 列是 2。如果显示 1，说明还是 WSL 1，需要手动转换：

powershell复制wsl --set-version Ubuntu 2

接着验证 Docker：

bash复制docker version
docker info --format '{{.OSType}}'

docker info --format '{{.OSType}}' 输出为 linux，说明 Docker 引擎确实运行在 Linux 内核之上。到这里，Windows 原生跑 Linux 容器的环境就算搭好了。

5. 功能测试与效果验证

环境搭好只是第一步，接下来按“最小容器 -> 端口映射 -> 目录挂载 -> 多容器编排”的顺序逐个验证。

5.1 最小容器验证

先拉一个最小的镜像测试整条链路：

bash复制docker run --rm hello-world

如果输出包含 Hello from Docker! 以及 “This message shows that your installation appears to be working correctly”，说明镜像拉取、容器创建、引擎执行链路都没问题。这一步失败基本就是网络、磁盘或虚拟化问题，直接看第 8 节排查。

5.2 Nginx 端口映射测试

最小验证通过后，跑一个真正提供服务的容器：

bash复制docker run -d --name web-test -p 8080:80 nginx:stable-alpine

容器启动后打开浏览器，访问 http://localhost:8080，能看到 Nginx 默认欢迎页就说明端口映射成功。注意这里的端口映射逻辑：-p 8080:80 表示宿主机 8080 端口转发到容器 80 端口。如果 8080 被 Windows 上的其他程序占用，会直接报端口冲突，换个端口再试：

bash复制docker run -d --name web-test -p 8081:80 nginx:stable-alpine

验证完成后清理容器：

bash复制docker stop web-test
docker rm web-test

5.3 目录挂载与文件交互

实际项目很少只跑容器不挂文件。测试 Windows 目录和容器目录的互通：

bash复制mkdir D:\docker-test

bash复制docker run -d --name web-mount -v D:\docker-test:/usr/share/nginx/html:ro -p 8082:80 nginx:stable-alpine

然后在 D:\docker-test 下放一个 index.html，内容随便写一句中文，刷新 http://localhost:8082 应该能看到这个文件。这说明 Windows 文件系统通过 WSL 2 的挂载机制共享到了容器内。

一个性能要点：跨 /mnt/c 的路径访问存在额外的文件系统转换开销，大量读写会很慢。更合理的做法是把项目放到 WSL 发行版的 Linux 目录里，比如 /home/用户名/project，再挂载进容器。

5.4 多容器编排测试

单容器验证完，用 Compose 测试多容器编排。新建一个项目目录，比如 D:\compose-test，里面创建 docker-compose.yml：

yaml复制services:
  nginx:
    image: nginx:stable-alpine
    ports:
      - "8083:80"
    volumes:
      - ./html:/usr/share/nginx/html:ro
  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"

在目录下执行：

bash复制docker compose up -d

这个命令会同时启动 Nginx 和 Redis 两个容器。执行 docker compose ps 可以看到两个服务都是 running 状态。测试 Redis 是否可用：

bash复制docker exec -it compose-test-redis-1 redis-cli ping

返回 PONG 就说明第二个容器也正常运行。同理，如果你需要 Elasticsearch，也可以按官方镜像方式启动，关键是注意环境变量，例如单节点模式要设置 discovery.type=single-node：

bash复制docker run -d --name es-test -p 9200:9200 -e "discovery.type=single-node" -e "xpack.security.enabled=false" docker.elastic.co/elasticsearch/elasticsearch:8.14.3

镜像版本以官方仓库实际存在的标签为准，如果拉不到，换成本机缓存或官方文档列出的其他版本。访问 http://localhost:9200 能看到 JSON 格式的版本信息，说明启动成功。

5.5 测试判断标准

6. 接口 API 与批量任务

Docker 的价值不只是交互式敲命令，它能作为自动化任务的底座。这里拆成 Docker Engine API 和批量任务两部分。

6.1 Docker Engine API

Docker CLI 本质上就是 Docker Engine API 的客户端。Windows 上安装 Docker Desktop 后，引擎默认暴露在命名管道 npipe:////./pipe/docker_engine，本机程序可以直接调用。如果你想用 HTTP REST 方式测试，可以在 Docker Desktop 里临时开启 TCP 暴露，但只建议在本地开发环境开启，生产环境必须使用 TLS 且不要绑定非本机地址。

开启后，可以用 curl 直接请求：

bash复制# 获取本机容器列表，2375 只应绑定在 127.0.0.1
curl http://127.0.0.1:2375/v1.41/containers/json?all=1

同样可以用 Python requests 验证：

python复制import requests

base = "http://127.0.0.1:2375"

# 获取所有容器列表
containers = requests.get(f"{base}/v1.41/containers/json?all=1", timeout=10)
print(containers.status_code)
for c in containers.json():
    print(c["Id"][:12], c["Names"], c["State"])

如果不希望开放 TCP，也可以用 Docker SDK for Python，它会自动识别 Windows 上的命名管道：

python复制import docker

client = docker.from_env()
for container in client.containers.list(all=True):
    print(container.id[:12], container.name, container.status)

注意，开放 2375 端口有安全风险，任何能访问该端口的人都能操作 Docker 引擎。用完立即关闭，或者在 Windows 防火墙里只放行本机回环地址。

6.2 批量拉取与批量启动

批量任务不一定要写多复杂的调度代码，Shell 循环就能做基础批量工作。例如批量拉取多个镜像：

bash复制for img in your-image:tag another-image:tag; do
  docker pull "$img"
  echo "--- pulled $img ---"
done

批量启动多个同类型容器时，用循环加序号命名：

bash复制for i in $(seq 1 5); do
  docker run -d --name worker-$i your-image:tag
done

更工程化的做法是用 Compose 定义服务，然后通过参数控制副本数量：

bash复制docker compose up -d --scale worker=3

6.3 资源限制与批量编排

批量任务必须做好资源隔离，否则一批任务上来可能把整机内存吃光。Compose 文件里可以声明资源限制：

yaml复制services:
  worker:
    image: your-image:tag
    deploy:
      resources:
        limits:
          cpus: '0.5'
          memory: 512M

这样每个 worker 最多占用半个 CPU 核和 512MB 内存。实际批量处理时，建议给每个任务加日志目录，并让容器退出码和任务状态对应，后续用脚本统一检查：

bash复制# 检查所有退出的容器
docker ps -a --filter "status=exited" --format "table {{.Names}}\t{{.Status}}"

7. 资源占用与性能观察

7.1 观察指标

WSL 2 运行时会有一个名为 vmmem 或 vmmemWSL 的进程出现在任务管理器里，那是 WSL 2 虚拟机的整体内存。更精确的观察要进容器内部：

bash复制docker exec -it 容器名 bash -c "free -h && echo '---' && nproc"

free -h 看内存，nproc 看 CPU 核心数。需要意识到的是，容器内看到的资源上限受 WSL 2 配置约束，不是 Windows 的全部资源。

启动指标方面，Docker Desktop 首次冷启动偏慢，因为要先拉起 WSL 2 虚拟机再启动引擎；热启动明显更快。如果 WSL 2 发行版长期空闲，建议执行 wsl --shutdown 释放资源，下次用 Docker 时再自动启动。

7.2 控制内存与 CPU

用户主目录下新建 .wslconfig 文件，可以全局限制 WSL 2 虚拟机的资源：

ini复制[wsl2]
memory=4GB
processors=2
swap=2GB

修改后执行 wsl --shutdown 让配置生效。Docker Desktop 里也可以在 Settings -> Resources 里限制 WSL 2 后端资源，两者取更严格的生效。注意 memory 设置太小会导致容器内存不足，尤其跑 Elasticsearch 这类重内存中间件时，要适当调高，或单独给容器设置下限。

7.3 性能优化建议

WSL 2 的文件性能有两个关键规律：

• Linux 文件系统（ext4）内部读写性能接近原生 Linux。
• 跨 Windows 目录 /mnt/c/... 的文件 IO 明显更慢，频繁小文件读写尤其明显。

所以项目源码、构建缓存、依赖目录都要放到 WSL 发行版内部，避免放在 C 盘再挂进容器。如果你只是把容器当中间件用，平时从 PowerShell 敲命令，影响不大；如果你在容器里跑编译、跑测试，就要尽早把工作目录迁到 Linux 侧。

8. 常见问题与排查方法

这里想单独强调一个坑：很多人 docker pull 失败第一反应是换网络工具，但更稳妥的顺序是先确认 Docker 引擎能否访问镜像仓库、有没有配置系统代理、防火墙有没有放行。把日志读全，再动手调整。

9. 最佳实践与使用建议

跑通之后，建议按下面这套思路做工程化管理，避免环境越用越乱：

1. 第一次先小参数测试。不要一上来就编排十几个容器，先 hello-world，再 Nginx，最后 Compose。
2. 保留一套最小可运行配置。把 .wslconfig、Docker Desktop 设置、常用 Compose 文件存到一个配置文件仓库里，换机器能快速复现。
3. 目录分开管理。模型文件、输入素材、输出结果、容器数据卷分目录存放，不要全部堆在用户目录。
4. 批量任务加日志和失败重试。脚本循环里记录每个容器的启动结果和退出码，失败任务单独打印日志。
5. 接口服务限制访问范围。2375 这类管理端口不要暴露到局域网，使用默认命名管道或 TLS。
6. 镜像安全要前置。公共镜像先看来源和下载量，部署前做漏洞扫描，涉及敏感数据的镜像不要推到公开仓库。
7. 涉及人脸、声音、版权素材的容器应用，必须确认授权。容器只是运行环境，数据合规责任在业务侧。
8. 发布或商用前做效果复核。本地容器通过不等于生产环境可用，端口、环境变量、资源限制都要再核对。

10. 总结与下一步

Windows 上用 WSL 2 + Docker Desktop 跑 Linux 容器，最大的价值是把“本地中间件环境”这件事的成本降到了最低。最值得先试的操作是 docker run -d -p 8080:80 nginx:stable-alpine，一条命令就能看到容器端口和 Windows 主机的连通性；最容易踩的坑是 BIOS 虚拟化没开和 WSL 2 内存占用不释放，前者装不上，后者会影响整机体验。

接下来可以按两个方向扩展：一是把 Docker Desktop 内置的单节点 Kubernetes 打开，学习 Pod、Service、Deployment 的本地编排；二是把项目迁移到 WSL 发行版内部目录，配合 Compose 建立一套可复现的开发环境。如果你以前习惯用虚拟机跑 Linux 容器，这周就可以先装一套 WSL 2 试试，对比一下启动速度和日常操作的顺手程度，大概率不会再换回去。