WSL 2 + Docker Desktop 原理与实战：Windows 容器开发全链路解析

1. 这不是“装个软件”那么简单：为什么 WSL 2 + Docker Desktop 组合让无数 Windows 开发者从崩溃到真香

你是不是也经历过——在 Windows 上敲下 docker --version，终端却冷冷地返回 command not found；或者双击 Docker Desktop 图标，弹出一个红色警告框：“Virtualization support not detected”、“WSL not installed”、“Docker engine failed to start”……然后你翻遍知乎、CSDN、Stack Overflow，看到的教程要么是“打开 BIOS 开启 VT-x”，要么是“升级到 Windows 11”，要么是“重装系统”，最后瘫在椅子上，盯着屏幕想：我到底只是想跑个 Redis 容器，怎么比部署生产环境还难？

这根本不是你的问题。这是 Windows 原生容器生态长期存在的结构性断层：Windows 内核不原生支持 Linux 容器运行时，而 Docker 的核心（containerd、runc、overlayfs）全构建在 Linux 内核能力之上。过去靠 Hyper-V 虚拟机硬扛，资源开销大、文件 I/O 慢、网络配置绕、与 Windows 工具链割裂——直到 WSL 2 的出现，才真正把“Linux 内核兼容层”塞进了 Windows 的血管里。它不是模拟器，不是虚拟机，而是一个轻量级、专为 Linux 二进制设计的完整内核实例，启动毫秒级、内存共享、文件系统直通、端口自动映射。Docker Desktop 4.0+ 版本正是吃透了这个红利，把 Docker Engine 直接下沉到 WSL 2 发行版中运行，自己只做 UI 和跨平台桥接。所以你现在要装的，从来就不是“Docker Desktop”这个图标，而是整套 Windows 与 Linux 容器世界的协议栈对接工程。它涉及 CPU 微指令级支持（Intel VT-x / AMD-V）、Windows 内核模块（WSL2.sys）、Linux 内核模块（overlay、cgroup v2）、发行版初始化系统（systemd 支持）、Docker 引擎配置、镜像仓库代理、甚至 PowerShell 与 Bash 的环境变量穿透。每一个环节卡住，都会在界面上表现为一句冰冷的错误提示。但好消息是：只要理清逻辑链条，95% 的失败都源于三类可预判、可验证、可修复的配置断点——BIOS 层的硬件开关、Windows 系统层的组件启用、WSL 发行版层的服务就绪。这篇文章，就是按这三层结构，带你一锤一锤敲实每一块砖。不讲虚的“下载安装包→下一步→完成”，只讲你双击图标前，系统底层到底发生了什么、为什么必须这样、哪里最容易被忽略。适合所有正在被 0x800f080c、exit status 0xffffffff、virtualisation support wasn't detected 折磨的 Windows 开发者、数据工程师、AI 研究员，以及任何需要在本地复现 Linux 生产环境的从业者。

2. 核心设计逻辑拆解：为什么必须是 WSL 2？为什么不能跳过 Docker Desktop？为什么“一键安装”全是坑？

2.1 WSL 2 不是 WSL 1 的升级版，而是两种完全不同的技术范式

很多人以为 WSL 2 就是“WSL 1 加了个内核”，这是最大的认知陷阱。WSL 1 的本质是 系统调用翻译层（syscall translation layer）：它把 Linux 的 open()、fork()、mmap() 等系统调用，实时翻译成 Windows NT 内核能理解的等价操作。好处是启动快、内存占用低；坏处是它永远无法 100% 精确模拟 Linux 内核行为——比如 inotify 文件监控在某些路径下失效、/proc 和 /sys 文件系统信息不全、cgroup 控制组功能缺失。而 Docker Engine 的核心依赖恰恰是这些：它需要 cgroup v2 来限制容器 CPU/内存配额，需要 overlayfs 来实现镜像分层，需要 namespaces 来隔离进程和网络。WSL 1 根本不提供这些内核接口，所以 Docker Desktop 在 WSL 1 下只能退化为“仅客户端模式”，即 Windows 上跑一个 Docker CLI，通过 TCP 连接到远端 Linux 服务器上的 Docker Daemon——这已经脱离了“本地开发”的初衷。

WSL 2 则完全不同。它基于轻量级虚拟机管理程序（Lightweight Utility VM），在 Windows Hypervisor Platform（WHPX）之上启动一个真实的、精简版的 Linux 内核（5.10+）。这个内核具备完整的 cgroup v2、overlayfs、namespaces、seccomp 支持，且与宿主 Windows 共享物理内存（内存页自动交换）、文件系统通过 9P 协议双向挂载（/mnt/c 是 Windows C 盘，\\wsl$\Ubuntu\home\user 是 WSL 中的 home 目录）。这意味着：Docker Engine 可以像在 Ubuntu 物理机上一样，在 WSL 2 内核中直接运行，无需任何翻译或适配。官方测试数据显示，WSL 2 下 docker build 的 I/O 性能比 WSL 1 提升 3-5 倍，docker run 启动延迟从秒级降至毫秒级。所以，“必须用 WSL 2”不是 Docker Desktop 的强制捆绑策略，而是技术可行性的硬性门槛——没有 WSL 2 的内核能力，Docker Desktop 就失去了本地运行引擎的物理基础。

2.2 Docker Desktop 不是“Docker 的图形界面”，而是 Windows 容器生态的中枢协调器

另一个常见误解是：“我既然有 WSL 2，为什么不直接在 Ubuntu 发行版里 apt install docker.io？” 这条路理论上可行，但实践中会迅速陷入泥潭。原因在于：Docker Desktop 承担了 WSL 2 与 Windows 之间 四层关键协调工作，而社区版 docker.io 完全不处理这些：

1. 跨子系统服务发现与端口映射：当你在 WSL 2 的 Ubuntu 里运行 docker run -p 8080:80 nginx，容器监听的是 WSL 2 的 127.0.0.1:8080。但你在 Windows 的 Chrome 里访问 http://localhost:8080，请求必须能穿透 WSL 2 的网络栈，到达容器。Docker Desktop 在 WSL 2 中部署了一个 dockerd 实例，并在 Windows 主机上运行一个 com.docker.backend.exe 进程，二者通过命名管道通信，自动将 WSL 2 的 127.0.0.1 端口映射到 Windows 的 127.0.0.1，用户完全无感。而手动安装的 docker.io 默认不开启此桥接，你需要手动配置 iptables 规则、修改 WSL 2 的 /etc/wsl.conf 网络设置，甚至重启 WSL 2，稍有不慎就导致端口冲突或连接超时。

2. Windows 文件系统与 Linux 容器的无缝挂载：Docker 镜像构建常需挂载 Windows 项目目录（如 C:\myapp）作为构建上下文或运行时卷。Docker Desktop 自动将 C:\ 映射为 WSL 2 的 /mnt/c，并在 dockerd 启动时注入正确的 --data-root 和 --exec-opt native.cgroupdriver=systemd 参数，确保挂载路径在容器内可读写。手动安装的 docker.io 默认使用 /var/lib/docker 作为数据根目录，若你强行用 -v /mnt/c/myapp:/app 挂载，会因 WSL 2 的 9P 文件系统权限模型（默认 uid=0,gid=0,umask=022）导致容器内进程无权写入，报错 Permission denied。

3. Windows 用户身份与 Linux 容器权限的自动对齐：在 WSL 2 中，你的 Windows 用户账户（如 DOMAIN\user）被映射为 WSL 2 的 UID/GID。Docker Desktop 在启动 dockerd 时，会自动读取当前 Windows 用户的 SID，并在容器内创建同名用户，确保 docker run -u $(id -u):$(id -g) 能正确继承宿主权限。手动安装的 docker.io 无此逻辑，容器内默认以 root 运行，或需手动 usermod，极易引发权限混乱。

4. GUI 应用与资源监控的统一入口：Docker Desktop 提供可视化仪表盘（Containers、Images、Volumes）、实时资源监控（CPU/Mem/Disk I/O）、一键清理未使用资源、镜像仓库登录管理、Kubernetes 集群切换等功能。这些不是简单的 GUI 包装，而是深度集成 WSL 2 的 systemd 日志、cgroup 统计、docker events 流。手动安装 docker.io 后，你只能靠 docker stats、htop、journalctl 等命令行工具拼凑信息，开发调试效率断崖式下降。

因此，“跳过 Docker Desktop”看似省事，实则是把本该由专业工具解决的跨平台协调问题，全部甩给开发者用脚本和 Google 解决。Docker Desktop 的价值，不在于它多了一个图标，而在于它把 Windows 和 Linux 两大生态之间那些看不见的胶水，全部封装成了开箱即用的确定性行为。

2.3 “一键安装”失败的三大根源：硬件、系统、发行版，缺一不可

网络上大量“Docker Desktop 安装失败”的帖子，其错误代码高度集中于三类：

• 0x800f080c：Windows 功能启用失败，本质是 Containers 或 VirtualMachinePlatform Windows 功能未成功激活；
• Virtualization support not detected：CPU 硬件虚拟化未开启，或 Windows Hypervisor Platform（WHPX）被禁用；
• WSL not installed 或 exit status 0xffffffff：WSL 2 内核未下载，或默认发行版未设为 WSL 2 模式。

这三类错误，分别对应着 硬件层 → 系统层 → 发行层 的三级依赖链。任何一级断裂，整个链条就崩塌。而所谓“一键安装包”，只是把 Docker Desktop 的二进制文件和安装脚本打包，它不负责帮你开启 BIOS 中的 VT-x、不负责帮你启用 Windows 功能、不负责帮你下载 WSL 2 内核。它只在所有前置条件满足后，才开始执行自己的安装逻辑。所以，真正的安装流程，必须是 逆向验证：先确认硬件支持，再确认系统组件就绪，最后确认 WSL 2 发行版可用，最后才是 Docker Desktop 安装。跳过任一环节的验证，都等于在没打地基的情况下盖楼。下面我们就按这个顺序，逐层夯实。

3. 实操全流程详解：从 BIOS 设置到第一个容器运行，每一步都附带原理说明与避坑指南

3.1 第一层：硬件层验证与 BIOS 设置（决定性前提）

Docker Desktop + WSL 2 的基石，是 CPU 的硬件虚拟化能力。Intel 称之为 VT-x（Virtualization Technology for x86），AMD 称之为 AMD-V（AMD Virtualization）。这不是软件开关，而是 CPU 芯片出厂时就固化在微码中的指令集扩展。如果 BIOS 中关闭了它，无论 Windows 多么新、WSL 2 内核多先进，Docker Engine 都无法启动。

验证方法（无需重启）： 在 Windows PowerShell（管理员）中执行：

若输出中包含 VM Monitor Mode Extensions: Yes、Virtualization Enabled In Firmware: Yes、Second Level Address Translation: Yes，说明硬件支持且已启用。若 Virtualization Enabled In Firmware 显示 No，则必须进 BIOS 设置。

BIOS 进入与设置（通用步骤，品牌略有差异）：

1. 重启电脑，在开机自检（POST）画面出现时，狂按 F2（Dell/HP）、Del（ASUS）、F10（Lenovo）或 Esc（部分品牌）进入 BIOS Setup。
2. 导航至 Advanced → CPU Configuration 或 Security → System Security 或 Configuration → Virtualization。
3. 找到以下选项并设为 Enabled：
   • Intel Virtualization Technology（Intel CPU）
   • Intel VT-d Feature（Intel CPU，用于 DMA 直通，WSL 2 非必需但建议开启）
   • SVM Mode（AMD CPU）
4. 保存设置（通常 F10 → Yes），重启。

提示：部分笔记本（尤其是企业版 ThinkPad、Dell Latitude）的 BIOS 中，虚拟化选项可能被隐藏在 Security → Memory Protection → Execute Disable Bit 下，或需要先设置管理员密码才能解锁。若找不到，可尝试在 Windows 中运行 Intel Processor Identification Utility 或 AMD Ryzen Master，它们会直接报告 VT-x/AMD-V 状态。

避坑指南：

• Windows Sandbox 与 WSL 2 冲突？ 不会。Windows Sandbox 也依赖 WHPX，但它与 WSL 2 共享同一套 Hypervisor，互不干扰。开启 Sandbox 反而是验证 WHPX 正常工作的快捷方式：在 Windows 设置 → 应用 → 可选功能中启用 Windows Sandbox，重启后能正常运行，即证明 WHPX 已就绪。
• Hyper-V 与 WSL 2 兼容吗？ 完全兼容。WSL 2 的底层就是 WHPX，而 Hyper-V 也是构建在 WHPX 之上的。Docker Desktop 官方明确支持 Hyper-V 和 WSL 2 并存。但注意：如果你同时运行 VMware Workstation 或 VirtualBox，它们可能与 WHPX 冲突（因抢占同一 Hypervisor），此时需在 BIOS 中禁用 Hyper-V（通过 bcdedit /set hypervisorlaunchtype off），或改用 WSL 2 专用的 wsl --update 方式更新内核。

3.2 第二层：Windows 系统层组件启用（强制性步骤）

即使硬件支持，Windows 也必须显式启用两个核心功能：VirtualMachinePlatform（提供 WSL 2 运行时）和 WindowsSubsystemForLinux（提供 WSL 基础框架）。这两个功能默认是禁用的，必须通过 PowerShell（管理员）手动开启。

标准启用流程：

1. 以管理员身份打开 PowerShell（Win+X → Windows PowerShell (Admin)）。
2. 依次执行以下命令（每条命令后回车，等待执行完成）：

重启后，安装 WSL 2 内核更新包：

• 访问 Microsoft WSL 2 内核更新页面，下载 wsl_update_x64.msi。
• 双击安装，一路下一步。
• 安装完成后，在 PowerShell（管理员）中执行：

若输出类似：

说明 WSL 2 已就绪。

注意：wsl --set-default-version 2 命令必须在安装内核更新包后执行。若执行时报错 Invalid argument，说明内核包未安装或未重启。此时不要反复尝试，先确认 wsl_update_x64.msi 是否已成功安装（控制面板 → 程序和功能中应能看到 Windows Subsystem for Linux Update）。

避坑指南：

• 0x800f080c 错误的终极解法： 此错误代码表示 DISM 启用功能失败，90% 源于 Windows 更新组件损坏。解决方案是重置 Windows Update：在管理员 PowerShell 中依次执行：
  POWERSHELL 复制

  1

  net stop wuauserv

  2

  net stop cryptSvc

  3

  net stop bits

  4

  net stop msiserver

  5

  ren C:\Windows\SoftwareDistribution SoftwareDistribution.old

  6

  ren C:\Windows\System32\catroot2 catroot2.old

  7

  net start wuauserv

  8

  net start cryptSvc

  9

  net start bits

  10

  net start msiserver
  然后再次运行 dism 命令。
• WSL 1 与 WSL 2 共存？ 可以。wsl -l -v 中每个发行版右侧的 VERSION 列可单独设置：wsl --set-version Ubuntu-22.04 2。但 Docker Desktop 强烈建议所有发行版都设为 WSL 2，否则混合模式下可能出现网络或文件系统不一致。

3.3 第三层：WSL 发行版层初始化与 Docker Engine 就绪（关键衔接点）

WSL 2 内核已加载，但 Docker Engine 还未在其中运行。Docker Desktop 的安装包，本质上是在 WSL 2 的默认发行版（通常是 Ubuntu）中，部署一个预配置的 dockerd 服务，并将其注册为 systemd 服务（WSL 2 22.04+ 默认启用 systemd）。

手动验证 WSL 2 发行版是否具备 Docker 运行条件：

1. 启动你的 WSL 2 发行版（如 Ubuntu）。
2. 在终端中执行：

理想输出：

若 systemd 未运行（常见于旧版 WSL 2）： 编辑 /etc/wsl.conf：

添加以下内容：

保存后，退出 WSL（exit），在 PowerShell 中执行 wsl --shutdown，再重新启动发行版。ps -p 1 -o comm= 应返回 systemd。

提示：/etc/wsl.conf 是 WSL 2 的全局配置文件，systemd=true 是 Docker Desktop 正常工作的前提。很多教程忽略此步，导致 Docker Desktop 安装后 dockerd 无法自启。

避坑指南：

• docker desktop requires windows 10 pro/enterprise/home 22h2 (19045) or windo 错误： 这是 Docker Desktop 安装程序的版本检测逻辑。它检查的是 Windows Build Number（如 19045 对应 Win10 22H2）。若你用的是 Win10 21H2（Build 19044），安装程序会拒绝。解决方案：下载旧版 Docker Desktop（如 4.15.0），它支持 Build 19042+。新版 Docker Desktop 4.20+ 已放宽此限制，但安装包仍会校验。最稳妥方式是升级 Windows：设置 → 更新与安全 → Windows 更新 → 检查更新。
• MATLAB 用户特别注意： MATLAB R2022a+ 原生支持 WSL 2，但其 matlab 命令行启动器默认调用 Windows 版本。若你想在 WSL 2 中运行 MATLAB 的 Linux 版本，需在 WSL 2 中手动安装 Linux 版 MATLAB，并确保 PATH 中 matlab 指向 /usr/local/MATLAB/R2023a/bin/matlab。Docker Desktop 与此无直接关联，但共用 WSL 2 环境，需避免端口冲突（MATLAB 默认用 31415 端口）。

3.4 第四层：Docker Desktop 安装与核心配置（落地执行）

现在，所有前置条件均已满足。可以开始 Docker Desktop 的安装。

下载与安装：

• 访问 Docker Desktop 官网下载页，选择 Windows 版本。
• 重要： 下载 Stable 通道的最新版（非 Edge），因其经过充分测试。截至 2024 年，推荐 4.28.0 或更高。
• 双击 Docker Desktop Installer.exe，全程默认设置（Add shortcut to desktop 可勾选）。
• 安装完成后，系统托盘会出现 Docker 鲸鱼图标。首次启动会弹出向导，点击 Next → Install。

首次启动后的关键配置：

1. WSL Integration 设置： 点击托盘图标 → Settings → General → 勾选 Use the WSL 2 based engine；然后进入 Resources → WSL Integration，找到你的 WSL 2 发行版（如 Ubuntu-22.04），务必勾选 Enable integration with my default WSL distro。这是 Docker Desktop 与 WSL 2 通信的开关。
2. 镜像源加速（国内用户必做）： Settings → Docker Engine，在 JSON 配置框中，找到 "registry-mirrors" 字段，添加国内镜像源：
   JSON 复制

   1

   {

   2

   "registry-mirrors": [

   3

   "https://docker.mirrors.ustc.edu.cn",

   4

   "https://hub-mirror.c.163.com",

   5

   "https://mirror.baidubce.com"

   6

   ],

   7

   "insecure-registries": []

   8

   }
   点击 Apply & Restart。此举可将 docker pull 镜像速度提升 5-10 倍。
3. 中文界面（可选）： Settings → Language → 选择 中文（简体） → Apply & Restart。

验证安装： 在 Windows PowerShell 或 WSL 2 终端中，执行：

若 docker run hello-world 成功，说明整个链路（Windows → WSL 2 → dockerd → container）已打通。

注意：docker run hello-world 第一次会较慢（需下载镜像），请耐心等待。若卡在 Unable to find image 'hello-world:latest' locally 后无响应，检查镜像源配置是否生效（docker info | grep -i mirror）。

4. 常见问题与排查技巧实录：从报错日志到根因定位，一份真实踩坑笔记

4.1 经典错误速查表

4.2 深度排查：如何读懂 Docker Desktop 的日志

当界面报错模糊时，日志是唯一真相来源。Docker Desktop 的日志分为三层：

1. Windows 主机日志： %LOCALAPPDATA%\Docker\log.txt，记录安装、启动、UI 交互事件。
2. WSL 2 发行版日志： 在 WSL 2 终端中执行 sudo journalctl -u docker.service -n 100 -f，实时查看 dockerd 服务日志。
3. Docker Desktop 内部日志： 托盘图标右键 → Troubleshoot → View logs，打开日志查看器。

实战案例：docker desktop failed to start because virtualisation support wasn't detected

• 查看 log.txt，发现一行：[W] WSL2: Failed to start WSL2 distro: exit code: 4294967295。
• 此 4294967295 即 0xffffffff，是 WSL 2 启动失败的通用错误码。
• 进入 WSL 2，执行 wsl -l -v，发现发行版状态为 Stopped。
• 执行 wsl -d Ubuntu-22.04，报错 The system cannot find the file specified.。
• 最终定位：wsl_update_x64.msi 未安装。因为 wsl --update 命令依赖此 MSI 包提供的内核镜像。解决方案：重新下载并安装内核更新包。

实战案例：starting the docker engine... docker engine is the underlying technology tha（日志截断）

• 此为 dockerd 进程启动超时。查看 journalctl -u docker.service，发现关键行：failed to start daemon: Devices cgroup isn't mounted。
• 原因：WSL 2 的 cgroup 挂载点异常。执行 sudo mkdir -p /sys/fs/cgroup/devices，然后 sudo mount -t cgroup -o devices none /sys/fs/cgroup/devices。
• 但此为临时修复。永久方案：在 /etc/wsl.conf 中添加：
  INI 复制

  1

  [boot]

  2

  command = "sudo mkdir -p /sys/fs/cgroup/devices && sudo mount -t cgroup -o devices none /sys/fs/cgroup/devices"

4.3 实操心得：那些文档里不会写的细节

• WSL 2 发行版的选择： 官方推荐 Ubuntu 22.04 LTS，因其内核（5.15）对 cgroup v2 和 overlayfs 支持最完善。避免使用 Debian 或 Alpine 作为 Docker Desktop 的集成发行版，因其默认 systemd 支持不完整，易导致 dockerd 服务无法自启。
• 磁盘空间管理： WSL 2 的虚拟硬盘（ext4.vhdx）默认动态增长，但不会自动收缩。docker system prune -a 只清理 Docker 数据，不清理 WSL 2 的 VHDX。若 C:\Users\YourName\AppData\Local\Packages\...\LocalState\ext4.vhdx 膨胀过大，可在 PowerShell 中执行：
  POWERSHELL 复制

  1

  wsl --shutdown

  2

  diskpart

  3

  # 在 diskpart 中依次执行：

  4

  # select vdisk file="C:\Users\YourName\AppData\Local\Packages\...\LocalState\ext4.vhdx"

  5

  # attach vdisk readonly

  6

  # compact vdisk

  7

  # detach vdisk
• 与 Windows 安全软件的兼容性： 某些国产杀毒软件（如 360、腾讯电脑管家）会拦截 WSL 2 的 wsl.exe 进程或 dockerd 的网络调用。若 Docker Desktop 启动异常，可临时禁用杀软，或将其加入白名单。
• Docker Desktop 的资源限制： 托盘图标右键 → Settings → Resources → Memory，建议至少分配 2GB。WSL 2 默认内存上限为 50% 宿主内存，若宿主内存小于 8GB，dockerd 可能因内存不足而崩溃。可编辑 %USERPROFILE%\AppData\Local\Packages\...\wsl.conf，添加 memory=3GB 限制。

5. 进阶应用与个人经验：从本地开发到生产仿真，一条平滑演进路径

Docker Desktop + WSL 2 的价值，远不止于运行一个 nginx 容器。它是一套完整的、面向现代开发者的 本地云原生环境沙盒。我在实际项目中，已将其用于以下场景，并总结出一套平滑演进路径：

阶段一：单服务本地调试（新手友好）

• 场景：前端 Vue 项目需连接后端 Spring Boot API，API 又依赖 MySQL 和 Redis。
• 实现：docker-compose.yml 定义 web、api、mysql、redis 四个服务，web 通过 http://api:8080 调用后端（Docker 内部 DNS 自动解析），api 通过 jdbc:mysql://mysql:3306/db 连接数据库。
• 优势：完全隔离，docker-compose up 一键启动整套环境，docker-compose down 一键销毁，不污染 Windows 本机端口和进程。

阶段二：多环境一致性保障（团队协作）

• 场景：团队成员 Windows/macOS/Linux 并存，要求 npm run dev 在任意系统上行为一致。
• 实现：将 package.json 中的 dev 脚本改为 docker-compose run --rm web npm run dev，web 服务基于 node:18-alpine 构建，Dockerfile.dev 中精确指定 NODE_ENV=development、CHOKIDAR_USEPOLLING=true（解决 WSL 2 文件监控问题）。
• 优势：彻底消灭“在我机器上是好的”问题。新人入职，git clone → docker-compose up，5 分钟内获得与 CI/CD 流水线完全一致的开发环境。

阶段三：CI/CD 流水线本地仿真（高级实践）

• 场景：GitHub Actions 流水线使用 ubuntu-latest runner 执行 docker build 和 docker push，但本地调试时无法复现镜像构建失败。
• 实现：在 WSL 2 中安装 act（GitHub Actions CLI），并配置 ~/.actrc：
  TEXT 复制

  1

  -P ubuntu-latest=ghcr.io/catthehacker/ubuntu:act-latest
  然后在项目根目录执行 act -j build，即可在本地 WSL 2 环境中，1:1 复现 GitHub Actions 的构建过程，包括 docker build 的每一层缓存、RUN 命令的执行环境、COPY 的文件权限。
• 优势：将 CI/CD 故障排查从“远程日志猜谜”变为“本地终端调试”，效率提升一个数量级。

我个人在实际使用中最深的体会是：Docker Desktop + WSL 2 的最大价值，不是它让你“能做什么”，而是它帮你“不用做什么”。
你不用再纠结“这个 Python 包在 Windows 上编译失败怎么办”，因为容器里跑的是 Ubuntu；
你不用再担心“Java 版本冲突”，因为每个服务有自己的 JDK；
你不用再为“Node.js 版本升级导致老项目崩掉”而焦虑，因为 Dockerfile 锁定了 node:16；
你甚至不用再为“同事的 MySQL 配置和我不一样”而扯皮，因为 docker-compose.yml 就是唯一的真相。
它把开发环境的不确定性，压缩到了一个 docker-compose.yml 文件里。而这个文件，是可以放进 Git 仓库、可以 Code Review、可以版本回滚的。这才是现代软件工程的