1. 项目概述：为什么在 Windows 上亲手搭一个本地镜像仓库，比直接 pull 公共镜像更值得花这 20 分钟？
你是不是也经历过这些场景：团队里五个人写同一个 Spring Boot 服务，每次改完代码都要mvn clean package→docker build -t myapp:dev .→ 等三分钟构建完 → 再docker push registry.hub.docker.com/yourname/myapp:dev→ 然后等 CI 流水线跑完拉取、部署、验证……结果发现只是改了个日志级别？或者更糟——测试环境用的镜像是昨天下午 4:17 构建的，而你上午 10:03 提交的修复还没进镜像，运维同学一脸困惑地问：“这个 bug 不是上周就修了吗？”
这就是典型的“镜像交付链路断层”——开发构建的镜像没地方存，只能硬塞进 Docker Hub（还要登录、限速、私有仓库收费），或者干脆docker save > myapp.tar发微信传给同事，再手动docker load < myapp.tar。这种操作在三人小团队里能撑两周，到五人以上，协作成本指数级上升。
而docker/docker desktop for window环境下创建本地镜像仓库这件事，本质不是“又学一个命令”，而是给你在本机 Windows 上立起一座可控、高速、离线可用的镜像中转站。它不依赖网络、不经过公网、不触发 Docker Hub 的速率限制，构建完docker tag myapp:dev localhost:5000/myapp:dev→docker push localhost:5000/myapp:dev，1 秒内完成；测试同学docker pull localhost:5000/myapp:dev，本地局域网直连，速度就是你的 SSD 读写速度。
关键词docker、docker desktop、window、本地镜像仓库、registry全部精准命中——这不是一个玩具实验，而是 Windows 开发者日常提效的刚需基建。尤其当你看到热搜里反复出现docker desktop failed to start because virtualisation support wasn't detected、window 10 按照 wsl、win11 docker desktop这些词时，就知道：大量 Windows 用户卡在环境准备这一步，根本没机会接触到“本地 registry”这个真正提升效率的环节。所以这篇内容，我不会从“registry 是什么”开始讲，而是直接带你绕过所有坑，在一台刚装好 Docker Desktop 的 Windows 电脑上，15 分钟内跑通本地仓库，并验证它比 Docker Hub 快 8 倍以上。适合所有用 Windows 做开发、测试、甚至轻量部署的工程师，无论你是写 Java、Python、Node.js 还是 Go，只要用 Docker，这个仓库就是你的“本地 Docker Hub”。
2. 整体设计与思路拆解：为什么不用 Docker Hub？为什么必须用 registry:2？为什么不能跳过 WSL2？
很多人第一反应是：“Docker Hub 不就能存镜像吗？干嘛自己搭？” —— 这是个典型误区。Docker Hub 是面向全球的公共分发平台，它的设计目标是广域分发，不是本地协作。它的瓶颈非常具体：
- 网络延迟：一次
docker push到registry.hub.docker.com，光 DNS 解析 + TLS 握手 + 认证校验就要 1.2~2.8 秒（实测 Win11 + 100M 宽带）； - 上传限速：免费账户单次 push 限速 128KB/s，一个 200MB 的 Spring Boot 镜像要传 26 分钟；
- 权限失控：你 push 到
yourname/myapp，别人只要知道名字就能 pull，私有性靠账号密码，但团队内部共享镜像不该靠“猜密码”； - 离线失效：公司内网断网？客户现场无外网？Docker Hub 直接变砖。
而本地镜像仓库（registry:2）的设计哲学完全相反：极简、单机、零依赖、纯 HTTP（可选 TLS）、只服务本机或局域网。它不处理用户管理、不提供 Web UI、不支持镜像扫描，就干一件事：把docker push过来的 tar 包存到本地磁盘，把docker pull的请求原样返回。这种“功能阉割”恰恰是它的优势——启动快（300ms 内）、内存占用低（常驻 35MB）、无外部依赖、配置项少于 5 个。
那为什么必须用registry:2，而不是自己写个 HTTP 服务存文件？因为registry协议本身有严格规范：镜像不是简单打包，而是由manifest.json（描述层结构）、config.json（容器配置）、多层layer.tar.gz（只读文件系统层）组成，且每层有 SHA256 校验和。docker push会按协议分步上传，docker pull会按需下载缺失层。自己实现协议至少要 2000 行代码，而registry:2镜像已由 Docker 官方维护十年，稳定度远超任何 DIY 方案。
至于为什么不能跳过 WSL2？这是 Windows 上 Docker Desktop 的底层机制决定的。Docker Desktop 在 Windows 上并非原生运行，而是通过 WSL2 启动一个轻量 Linux 虚拟机（默认 distro 是docker-desktop-data），所有容器、镜像、网络都在这个 VM 里运行。你执行docker run hello-world，实际是在 WSL2 里跑的。因此，当你运行docker run -d -p 5000:5000 --restart=always --name registry registry:2时，这个 registry 容器也运行在 WSL2 内部，它的localhost:5000对 WSL2 来说是本机，但对 Windows 主机来说，是\\wsl$\docker-desktop-data下的某个端口映射。Docker Desktop 默认会把 WSL2 的0.0.0.0:5000自动映射到 Windows 的localhost:5000，但前提是 WSL2 已启用且虚拟化支持正常。这也是为什么热搜里virtualization support not detected高频出现——如果 BIOS 里没开 Intel VT-x/AMD-V，或者 Windows 功能里没开“Windows Subsystem for Linux”，Docker Desktop 根本启动不了，更别说 registry。所以整个方案的前提，是先确保 WSL2 正常工作，这是不可绕过的地基。
3. 核心细节解析与实操要点：registry 容器的 5 个关键参数，每个都影响稳定性
运行 registry 容器看似就一条命令，但参数选错，轻则 push 失败，重则镜像损坏。我踩过三次坑，最后一次是因为-v挂载路径写错了，导致 registry 把镜像存到了 WSL2 的临时文件系统里，重启 Docker Desktop 后全丢了。下面逐个拆解docker run命令中每个参数的真实作用：
docker run -d \ -p 5000:5000 \ --restart=always \ --name registry \ -v /path/on/host:/var/lib/registry \ -e REGISTRY_HTTP_ADDR=0.0.0.0:5000 \ registry:23.1-p 5000:5000：端口映射不是“随便选个”，必须理解 WSL2 网络模型
-p 5000:5000表示把容器的 5000 端口映射到宿主机（即 Windows）的 5000 端口。这里的关键是：容器端口（右边）必须是registry:2默认监听的 5000，不能改；宿主机端口（左边）建议固定为 5000，避免后续脚本硬编码出错。有人想改成8080:5000，理论上可行，但所有docker push localhost:8080/myapp的命令都要同步改，增加协作成本。更重要的是，Docker Desktop 对 WSL2 的端口映射有缓存机制，如果第一次用8080，后来想切回5000，必须docker stop registry && docker rm registry彻底删除容器，否则旧映射残留导致新容器无法绑定端口。实测下来，坚持用5000:5000最省心。
3.2--restart=always：不是“为了高可用”，而是防 Docker Desktop 重启丢服务
--restart=always的作用常被误解为“保证 registry 7x24 运行”。实际上，在开发机上，你不需要它永远运行，但需要它在 Docker Desktop 重启后自动拉起。因为 Docker Desktop 关闭时，所有容器默认停止；重新打开时，只有加了--restart=always的容器才会自动启动。否则你每次开机都要手动docker start registry，而新手往往忘记这步，然后纳闷“为什么 push 报错 connection refused”。这个参数是“体验兜底”，不是“生产级高可用”。
3.3-v /path/on/host:/var/lib/registry：挂载路径必须指向 Windows 可持久化的目录
这是最致命的坑。/var/lib/registry是 registry 容器内存储镜像数据的路径，必须用-v挂载到宿主机的一个真实目录，否则数据存在容器临时文件系统里，容器删掉就全没了。但注意：不能挂载到 WSL2 的 Linux 路径（如/home/user/registry-data），必须挂载到 Windows 路径并通过 WSL2 访问。正确做法是：在 Windows 上新建一个文件夹，比如C:\docker-registry，然后在 WSL2 中用/mnt/c/docker-registry作为挂载源。命令变成：
docker run -d -p 5000:5000 --restart=always --name registry \ -v /mnt/c/docker-registry:/var/lib/registry \ registry:2为什么？因为/mnt/c/是 WSL2 访问 Windows C 盘的标准路径，它底层是 Windows 的 NTFS 文件系统，重启 WSL2 或 Docker Desktop 都不会丢失数据。而如果你用/home/user/registry-data，这个路径属于 WSL2 的 ext4 文件系统，当 Docker Desktop 执行“重置为出厂设置”时，整个docker-desktop-datadistro 会被格式化，数据彻底消失。我第一次就是挂载到/home下，重装 Docker Desktop 后哭着重做所有镜像。
3.4-e REGISTRY_HTTP_ADDR=0.0.0.0:5000：环境变量不是可选，而是解决“connection refused”的关键
registry 默认只监听127.0.0.1:5000（仅限容器内部访问），但我们需要从 Windows 主机docker push localhost:5000，这就要求 registry 监听0.0.0.0:5000（所有网络接口）。-e REGISTRY_HTTP_ADDR=0.0.0.0:5000就是告诉 registry 绑定到所有 IP。漏掉这个参数，curl http://localhost:5000/v2/会返回connection refused，因为 registry 根本没在0.0.0.0:5000上监听。这个参数必须加，没有例外。
3.5registry:2镜像标签：必须用:2，不能用:latest或:3
registry:2是当前稳定版，registry:3还在 beta 阶段，API 有 breaking change；registry:latest在某些 Docker 版本下会拉取到非预期版本。官方文档明确推荐registry:2。我试过registry:latest，在 Docker Desktop 4.25 上启动失败，报错unknown flag: --storage-driver，就是因为新版 registry 移除了旧参数。坚持用registry:2，版本可控，兼容性最好。
提示：所有参数必须一起使用，缺一不可。少一个，要么启动失败，要么运行不稳定。建议直接复制上面完整命令，替换
C:\docker-registry为你自己的路径。
4. 实操过程与核心环节实现：从零开始，15 分钟跑通本地仓库全流程
现在我们进入实操阶段。以下步骤基于一台已安装 Docker Desktop 4.20+、WSL2 已启用、BIOS 虚拟化已开启的 Windows 10/11 电脑。如果还不确定 WSL2 是否正常，请先在 PowerShell（管理员）中运行wsl -l -v，确认docker-desktop和docker-desktop-data两个 distro 状态为Running。如果显示Stopped，运行wsl --shutdown再重启 Docker Desktop 即可。
4.1 第一步：创建持久化存储目录（Windows 侧操作）
打开 Windows 文件资源管理器，在 C 盘根目录新建一个文件夹，命名为docker-registry。路径必须是C:\docker-registry（或其他盘符，如D:\docker-registry）。不要用中文路径、不要有空格、不要用 OneDrive 同步文件夹（OneDrive 会锁文件导致 registry 写入失败）。这个文件夹将作为 registry 的数据盘，所有镜像层都会存在这里。你可以右键属性 → 安全 → 编辑 → 添加Everyone用户并赋予“完全控制”权限（虽然通常不需要，但能避免极少数权限问题）。
4.2 第二步：启动 registry 容器（WSL2 侧操作）
打开 Docker Desktop 自带的终端（点击右上角鲸鱼图标 → “Troubleshoot” → “Open terminal”），或者直接打开 WSL2 终端（Win+R 输入wsl回车）。执行以下命令：
# 拉取 registry:2 镜像（首次需要，约 25MB） docker pull registry:2 # 创建并启动 registry 容器 docker run -d \ -p 5000:5000 \ --restart=always \ --name registry \ -v /mnt/c/docker-registry:/var/lib/registry \ -e REGISTRY_HTTP_ADDR=0.0.0.0:5000 \ registry:2执行后，终端会返回一长串容器 ID（如a1b2c3d4e5f6），表示容器已后台启动。运行docker ps | grep registry，应看到类似输出：
a1b2c3d4e5f6 registry:2 "/entrypoint.sh /etc…" 2 minutes ago Up 2 minutes 0.0.0.0:5000->5000/tcp registry如果STATUS显示Up X minutes，说明成功；如果显示Exited (1)，运行docker logs registry查看错误（常见原因是端口被占用或挂载路径不存在）。
4.3 第三步：验证 registry 服务是否可达（Windows 侧操作）
打开 Windows 的 PowerShell（无需管理员），执行：
curl -I http://localhost:5000/v2/如果返回HTTP/1.1 200 OK，说明 registry 服务已正常响应。如果返回Unable to connect或connection refused，请检查：
- Docker Desktop 是否正在运行（任务栏右下角有鲸鱼图标）；
docker ps是否显示 registry 容器状态为Up；- 防火墙是否阻止了 5000 端口（临时关闭防火墙测试）；
- 是否在 WSL2 终端里执行了
docker run（不是在 Windows CMD 里）。
注意：
curl在 Windows 10 1809+ 和 Win11 中原生支持，无需额外安装。如果提示curl command not found，用Invoke-WebRequest -Uri "http://localhost:5000/v2/"替代。
4.4 第四步：构建并推送一个测试镜像（全流程验证）
我们用最简单的hello-world镜像来测试完整流程。首先，确保本地有hello-world镜像：
docker pull hello-world然后打标签，指向本地 registry：
docker tag hello-world localhost:5000/hello-world:latest最后推送：
docker push localhost:5000/hello-world:latest如果看到The push refers to repository [localhost:5000/hello-world]和latest: digest: sha256:... size: 524，说明推送成功。此时，打开C:\docker-registry文件夹，你会看到自动生成的docker目录，里面是分层存储的镜像数据（_manifests、_layers等子目录），证明数据已落盘。
4.5 第五步：拉取并运行本地镜像（闭环验证）
删除本地的hello-world镜像，模拟“全新环境”：
docker rmi hello-world docker rmi localhost:5000/hello-world:latest然后从本地 registry 拉取：
docker pull localhost:5000/hello-world:latest拉取速度应该秒级完成（<1s），因为是本地磁盘读取。最后运行验证：
docker run localhost:5000/hello-world:latest终端输出Hello from Docker!，证明整个链路——构建、推送、拉取、运行——全部打通。
4.6 第六步：集成到日常开发（以 Maven 项目为例）
假设你有一个 Spring Boot 项目，pom.xml中已配置spring-boot-maven-plugin。在项目根目录执行：
# 构建 jar 并生成 Docker 镜像（假设 Dockerfile 在项目根目录） mvn clean package -DskipTests docker build -t myapp:dev . # 打标签为本地 registry 地址 docker tag myapp:dev localhost:5000/myapp:dev # 推送到本地仓库 docker push localhost:5000/myapp:dev # 部署时，其他机器只需 # docker pull localhost:5000/myapp:dev && docker run -p 8080:8080 localhost:5000/myapp:dev你会发现，docker push时间从 Docker Hub 的 2 分钟缩短到 3 秒以内，docker pull从 30 秒缩短到 0.5 秒。这才是本地仓库的真实价值——把镜像交付从“等网络”变成“本地 IO”。
5. 常见问题与排查技巧实录：那些官方文档不会写的“血泪经验”
在上百次搭建和教学中，我整理出 Windows 用户最常遇到的 7 类问题，附带一键排查命令和根治方案。这些问题 90% 都源于 Windows 环境特性和 Docker Desktop 的交互逻辑，不是 registry 本身的问题。
5.1 问题：docker desktop failed to start because virtualisation support wasn't detected
现象：Docker Desktop 启动失败，弹窗报错，任务栏无图标。
根因：Windows 未开启硬件虚拟化，或 Hyper-V/WSL2 功能未启用。
排查命令（PowerShell 管理员）：
# 检查虚拟化是否启用 systeminfo | find "Hyper-V Requirements" # 检查 WSL2 是否启用 wsl -l -v # 检查 Hyper-V 是否启用 Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V根治方案：
- 重启电脑进 BIOS（开机狂按 F2/F10/Del），找到
Intel Virtualization Technology或AMD-V，设为Enabled； - 在 Windows “启用或关闭 Windows 功能”中，勾选
Windows Subsystem for Linux和Virtual Machine Platform，重启； - 运行
wsl --install（Win11）或wsl --update（Win10），确保 WSL2 内核更新到最新。
注意：某些品牌机（如联想）BIOS 里叫
Intel VT-d，必须同时开VT-x和VT-d。
5.2 问题：curl http://localhost:5000/v2/返回connection refused
现象：registry 容器docker ps显示Up，但无法访问。
根因：registry 未监听0.0.0.0，或 Docker Desktop 端口映射未生效。
排查命令：
# 进入 registry 容器查看监听端口 docker exec -it registry netstat -tuln | grep :5000 # 检查容器日志 docker logs registry根治方案：
- 确保启动命令中包含
-e REGISTRY_HTTP_ADDR=0.0.0.0:5000； - 如果之前启动过 registry，先
docker stop registry && docker rm registry彻底删除，再用完整命令重跑； - 检查 Windows 防火墙是否阻止了 5000 端口（临时关闭测试）。
5.3 问题：docker push localhost:5000/myapp报错unauthorized: authentication required
现象：推送时提示需要认证，但 registry 默认是匿名的。
根因：Docker Desktop 的daemon.json中配置了insecure-registries，但未添加localhost:5000。
排查命令：
# 查看 daemon.json 配置 cat /etc/docker/daemon.json根治方案：
- 在 Docker Desktop 设置 → Docker Engine 中，找到
insecure-registries字段； - 添加
"localhost:5000"到数组中，例如：
{ "insecure-registries": ["localhost:5000"] }- 点击
Apply & Restart。
注意：
insecure-registries是必须的，因为本地 registry 默认用 HTTP（非 HTTPS），Docker 客户端默认拒绝连接不安全的 registry。
5.4 问题：推送成功，但C:\docker-registry目录为空
现象：docker push返回 success，但 Windows 文件夹里没文件。
根因：挂载路径错误，registry 实际写入了容器内部临时路径。
排查命令：
# 进入容器查看 /var/lib/registry 目录 docker exec -it registry ls -la /var/lib/registry # 检查挂载是否生效 docker inspect registry | grep -A 10 Mounts根治方案：
- 确认挂载路径是
/mnt/c/docker-registry（不是/c/docker-registry或C:\docker-registry）； - 确认
C:\docker-registry文件夹在 Windows 中真实存在且可写； - 删除容器重试：
docker stop registry && docker rm registry && docker run ...。
5.5 问题：docker pull localhost:5000/myapp报错no basic auth credentials
现象：拉取时提示认证失败。
根因：Docker 客户端尝试用 Docker Hub 凭据去连本地 registry。
根治方案：
- 运行
docker logout清除所有 registry 凭据； - 如果之前登录过 Docker Hub，
docker login会缓存凭据，必须docker logout后再docker pull； - 无需为本地 registry
docker login，它是匿名的。
5.6 问题：registry 容器内存占用飙升到 1GB+
现象：docker stats显示 registry 内存持续增长，最终 OOM 被 kill。
根因：registry 默认不清理垃圾数据，长期运行后缓存膨胀。
根治方案：
- 定期执行垃圾回收（需 registry v2.7+）：
# 进入 registry 容器执行 docker exec -it registry registry garbage-collect /etc/docker/registry/config.yml- 更简单的方法：每周
docker stop registry && docker rm registry，然后docker run重建，因为数据在挂载卷里，重建容器不影响镜像。
5.7 问题：在 IDEA 中打包 Docker 镜像时，docker push失败
现象：IDEA 的 Maven 插件执行docker:push，报错unable to push to localhost:5000。
根因：IDEA 默认使用 Windows 的 Docker CLI，但localhost:5000对 Windows CLI 是可达的，问题常出在插件配置。
根治方案：
- 在 IDEA 的
Settings → Build → Docker中，确认 Docker server URL 是unix:///var/run/docker.sock（WSL2 模式）； - 在 Maven
pom.xml的docker-maven-plugin配置中，<url>设为https://localhost:2376（不推荐）或留空（自动检测）； - 最可靠方法：在 IDEA 终端中手动执行
docker push，绕过插件。
| 问题编号 | 现象 | 一键排查命令 | 根治方案 |
|---|---|---|---|
| 5.1 | Docker Desktop 启动失败 | systeminfo | find "Hyper-V" | BIOS 开 VT-x，启用 WSL2 功能 |
| 5.2 | curl连接被拒 | docker exec registry netstat -tuln | 加-e REGISTRY_HTTP_ADDR=0.0.0.0:5000 |
| 5.3 | 推送提示未授权 | cat /etc/docker/daemon.json | 在 Docker Desktop 设置中添加localhost:5000到insecure-registries |
| 5.4 | 挂载目录为空 | docker inspect registry | grep Mounts | 挂载路径必须为/mnt/c/xxx |
| 5.5 | 拉取提示无认证凭据 | docker info | grep -i registry | 执行docker logout |
| 5.6 | registry 内存暴涨 | docker stats registry | 每周重建容器或执行garbage-collect |
| 5.7 | IDEA 推送失败 | docker context ls | 在 IDEA 设置中确认 Docker server URL |
6. 进阶技巧与实战扩展：让本地仓库真正融入你的工作流
搭好 registry 只是起点，让它真正提升效率，还需要几个关键扩展。这些不是“锦上添花”，而是解决真实痛点的必备技能。
6.1 技巧一：用docker-compose.yml管理 registry，告别命令行记忆
手动敲docker run命令容易出错，且参数难复现。用docker-compose可以把配置固化为文件。在C:\docker-registry目录下新建docker-compose.yml：
version: '3.8' services: registry: image: registry:2 restart: always ports: - "5000:5000" environment: REGISTRY_HTTP_ADDR: 0.0.0.0:5000 volumes: - /mnt/c/docker-registry:/var/lib/registry然后在该目录下运行docker-compose up -d，即可一键启动。停止用docker-compose down。好处是：配置集中管理、可 Git 版本控制、团队成员一键复现相同环境。我所有项目的本地 registry 都用此方式管理，再也不怕参数记错。
6.2 技巧二：为 registry 加上简易 Web UI，可视化镜像列表
registry 默认无界面，curl http://localhost:5000/v2/_catalog只能返回 JSON。装一个轻量 UI，比如joxit/docker-registry-ui：
docker run -d \ -p 8080:8080 \ --name registry-ui \ --link registry:registry \ -e REGISTRY_URL=http://registry:5000 \ -e REGISTRY_NAME=localhost:5000 \ joxit/docker-registry-ui:latest然后访问http://localhost:8080，就能看到所有已推送的镜像名和 Tag，点击可查看详情。UI 镜像只有 20MB，不增加负担，但极大提升调试效率——再也不用curl解析 JSON 了。
6.3 技巧三：配置 IDE 自动推送，让Ctrl+F9触发完整发布
以 IntelliJ IDEA 为例，在Settings → Build → Docker中配置 Docker server；然后在 Maven 项目中，编辑pom.xml的docker-maven-plugin：
<plugin> <groupId>io.fabric8</groupId> <artifactId>docker-maven-plugin</artifactId> <configuration> <images> <image> <name>localhost:5000/${project.artifactId}:${project.version}</name> <build> <dockerFileDir>${project.basedir}</dockerFileDir> </build> <run> <namingStrategy>alias</namingStrategy> </run> </image> </images> </configuration> </plugin>然后在 IDEA 中右键项目 →Maven → docker:build→docker:push，或者绑定到Build Project后自动执行。这样，写完代码按Ctrl+F9，IDEA 就自动构建、打标签、推送到本地 registry，全程无需切终端。
6.4 技巧四：用registry+nginx实现基础鉴权（无需 LDAP）
虽然本地仓库默认匿名，但团队协作时可能需要简单权限控制。不用上复杂的 Harbor，用nginx做反向代理加 Basic Auth 即可：
- 在
C:\docker-registry下新建htpasswd文件（用openssl passwd -crypt yourpassword生成）； - 新建
nginx.conf，配置location / { proxy_pass http://localhost:5000; auth_basic "Registry"; auth_basic_user_file /etc/nginx/htpasswd; }； - 运行
docker run -d -p 5000:80 -v /c/docker-registry:/etc/nginx:ro nginx。
这样docker login localhost:5000就需要输入用户名密码，满足小团队基本需求。
我个人在实际使用中发现，registry 的最大价值不是“替代 Docker Hub”，而是“消灭等待”。以前改一行代码要等 5 分钟才能验证，现在 10 秒内完成。这个时间差累积起来，一天能多跑 20 轮测试，一周多迭代 2 个功能点。而且，当你的本地仓库稳定运行三个月后，你会自然产生一个认知转变：镜像不再是“构建产物”，而是“一等公民”，它的生命周期管理（版本、清理、审计）会倒逼你优化整个 CI/CD 流程。所以别把它当成一个“临时方案”，从第一天起，就用生产级的态度去维护它——定期备份C:\docker-registry，写个批处理脚本每天凌晨docker system prune -f清理无用镜像，把它变成你 Windows 开发环境里最可靠的基础设施之一。
