docker desktop 本身不改变多阶段构建逻辑，它只是本地运行 docker engine 的 gui 封装；真正起作用的是你本地的 docker build 命令和 docker daemon。只要 docker desktop 启动正常、docker --version 显示 20.10+（推荐 24.0+），多阶段构建就完全可用——不需要额外配置。
Docker Desktop 本身不改变多阶段构建逻辑，它只是本地运行 Docker Engine 的 GUI 封装；真正起作用的是你本地的 docker build 命令和 Docker daemon。只要 Docker Desktop 启动正常、docker --version 显示 20.10+（推荐 24.0+），多阶段构建就完全可用——不需要额外配置。
怎么确认 Docker Desktop 已启用 BuildKit
BuildKit 是多阶段构建（尤其是带命名阶段、--from=、并行缓存）的底层支撑，默认在较新 Docker Desktop 中已开启，但必须显式启用才能生效：
检查是否启用：docker info | grep -i buildkit
如果输出含 BuildKit: true，说明已就绪；否则需手动开启。
启用方式（仅需一次）：
- 打开 Docker Desktop → Settings → Docker Engine
- 在 JSON 配置中添加或确认存在："features": {"buildkit": true}
- 点击 Apply & Restart
更直接的方式是每次构建时加环境变量：DOCKER_BUILDKIT=1 docker build -t myapp .
这个命令在 Docker Desktop 终端里执行完全有效，且优先级高于全局配置。
COPY --from= 阶段名不生效？常见原因
COPY --from=builder 报错 “no stage named ‘builder’” 或 “failed to compute cache key”，基本不是 Docker Desktop 的锅，而是 Dockerfile 或构建上下文问题：
- 阶段名拼写不一致：比如
FROM golang:1.23 AS build写成了build，但后面写COPY --from=builder——大小写、空格、连字符都要严格匹配 - 没用
AS命名：只写了FROM golang:1.23，没加AS builder，那只能用--from=0（第一阶段索引）引用，不推荐 - 构建上下文路径错误：比如
Dockerfile不在当前目录，用了-f ./build/Dockerfile，但忘记同步.dockerignore或 COPY 路径仍按旧路径写 - BuildKit 关闭状态下，某些老语法（如未命名阶段 +
--from=0）可能行为异常，建议统一启用 BuildKit
构建完怎么验证多阶段是否真起作用
别只看docker images 体积变小了就以为成功——得确认“构建工具链”确实没进最终镜像：
检查镜像层构成：docker history myapp
最后一两层应该只有 COPY 和 CMD，绝不能出现 apt install、npm ci、go build 这类指令。如果有，说明你误把构建阶段当最终镜像用了。
进容器看文件系统：docker run --rm -it myapp sh -c "ls -l /usr/local/bin/ && which go && echo \$PATH"
理想输出：只看到你的二进制（如 /usr/local/bin/myapp），没有 go、javac、node，PATH 也不含 /usr/local/go/bin 这类构建路径。
对比单阶段镜像：
用同一项目写个单阶段 Dockerfile（比如直接 FROM golang:1.23），构建后跑 docker images 对比体积——多阶段镜像应至少小 5–10 倍（例如 900MB → 65MB）。
多阶段构建的关键不在 Docker Desktop，而在你写的每一条 FROM、AS、COPY --from= 是否语义清晰、路径精准、阶段隔离彻底。最容易被忽略的是：即使启用了 BuildKit，如果 COPY --from= 指向了一个不存在的阶段名，Docker 也不会报错，而是静默跳过复制——结果就是最终镜像里啥也没有，启动失败。
