第02章：AI写的多阶段构建，镜像真的小又安全吗？

第02章：AI写的多阶段构建，镜像真的小又安全吗？

你需要把 Go 或 React 项目容器化，AI建议用多阶段构建（multi-stage build）来减小镜像体积。
AI给了你一个"build stage + run stage"的 Dockerfile，镜像确实小了很多。
但这个多阶段构建，真的做对了吗？

这一章告诉你：多阶段构建的正确用法，以及AI生成的多阶段Dockerfile有哪些常见错误。

ℹ️ 版本说明：本章基于 Docker Engine 27.x，多阶段构建从 Docker 17.05 开始支持，示例使用 Go 1.23 应用和 React + Node.js 22 前端项目。

2.1 AI默认会生成什么

Go 应用的多阶段构建（AI 默认版）：

FROM golang:1.23 AS builder
WORKDIR /app
COPY . .
RUN go build -o main .

FROM alpine:latest
WORKDIR /app
COPY --from=builder /app/main .
CMD ["./main"]

看起来很简洁，镜像也确实小了。但有3个问题被忽略了。

2.2 AI通常遗漏的3个坑

⚠️ 坑1：alpine:latest 的两个问题

第一，latest tag 是不固定的——今天构建和下周构建可能得到不同的版本，
导致"之前能跑，这次构建后就出错"。

第二，Alpine 使用 musl libc 而不是 glibc，如果你的 Go 二进制默认启用了 CGO（调用 C 代码），
运行时会报 not found 错误。即使你以为关闭了 CGO，某些隐含依赖（如 net 包在某些情况下）也会用到 CGO。

正确做法：用 CGO_ENABLED=0 确保纯静态编译，或者使用 gcr.io/distroless/static-debian12 代替 Alpine。

⚠️ 坑2：构建产物没有去除调试信息（二进制偏大）

go build -o main . 编译出的二进制默认包含调试符号（debug symbols）和DWARF信息。
这对线上运行毫无意义，但会让二进制增大20-30%。

正确做法：go build -ldflags="-s -w" -o main .

  • -s：去除符号表
  • -w：去除 DWARF 调试信息

⚠️ 坑3：React 前端构建没有利用 build cache（每次重装 node_modules）

AI 给 React 的多阶段构建通常是：

FROM node:22-alpine AS builder
WORKDIR /app
COPY . .          # ⚠️ 先复制了所有文件
RUN npm install   # 每次代码变了都重新 npm install
RUN npm run build

正确做法是先只复制 package.json 和 package-lock.json，安装依赖后再复制源代码——
这样只要 package.json 没变，npm install 那一层会命中缓存，极大加速构建。

2.3 更好的提示词

提示词 P01：生成正确的 Go 应用多阶段构建

使用时机：Go 应用容器化，需要最小化且静态的镜像。

你是一个 Docker 27 + Go 1.23 容器化专家。

请为我的 Go HTTP 服务生成生产级多阶段 Dockerfile：

应用信息：
- Go 版本：1.23
- 是否使用 CGO：[否（纯 Go） / 是（需要 C 库）]
- 应用监听端口：[如：8080]
- 是否有配置文件需要打包：[如：无，配置通过环境变量注入]

要求：
1. Build stage：
   - 使用 golang:1.23 构建
   - 设置 CGO_ENABLED=0 GOOS=linux GOARCH=amd64（静态编译）
   - 去除 debug 信息：-ldflags="-s -w"
   - 使用 go mod download 预拉依赖（利用缓存层）
   
2. Run stage：
   - 如果纯静态：使用 gcr.io/distroless/static-debian12（比 alpine 更安全，更小）
   - 如果需要 CA 证书（调用 HTTPS）：使用 gcr.io/distroless/base-debian12
   - 如果需要调试工具（开发环境）：alpine:3.20（固定版本）
   
3. 非 root 用户运行
4. HEALTHCHECK 使用 wget 或 curl 检查 /health 接口
5. 版本标签：构建时接受 BUILD_VERSION 参数，注入到 LABEL 和二进制的版本变量

给出带注释的完整 Dockerfile，并说明构建命令（docker build --build-arg BUILD_VERSION=xxx）。

提示词 P02：生成 React/Vue 前端的多阶段构建（+Nginx 服务）

使用时机：前端 SPA 应用需要容器化（构建 + Nginx 托管）。

你是一个 Docker 27 前端容器化专家。

请为我的 [React 18 / Vue 3] 应用生成生产级多阶段 Dockerfile：

项目信息：
- 包管理器：[npm / pnpm / yarn]
- 构建命令：[如：npm run build，输出到 dist/ 目录]
- Nginx 配置需求：[如：SPA 路由（所有路径返回 index.html）/ 有 /api 反向代理]

要求：
1. Build stage（Node.js 22 LTS）：
   - 先 COPY package.json package-lock.json（或 pnpm-lock.yaml）
   - RUN npm ci --frozen-lockfile（不是 npm install，更稳定）
   - 再 COPY . .（源代码）
   - RUN npm run build
   - 说明为什么这个顺序能最大化利用 Docker 层缓存

2. Run stage（Nginx）：
   - 使用 nginx:1.27-alpine（固定版本，不用 latest）
   - 生成对应的 nginx.conf：SPA路由配置 + gzip压缩 + 安全响应头
   - 非 root 用户运行 Nginx（nginx 官方镜像的非root方式）

3. .dockerignore：排除 node_modules、.env、.git 等

给出：Dockerfile + nginx.conf + .dockerignore 三个文件的完整内容。

提示词 P03：分析多阶段构建的镜像安全漏洞

使用时机：镜像构建完成后，用AI辅助安全扫描分析。

你是一个容器安全专家，熟悉 Docker Scout / Trivy 等镜像漏洞扫描工具。

我刚构建了一个镜像，运行了安全扫描，结果如下：
[粘贴 docker scout cves IMAGE_NAME 或 trivy image IMAGE_NAME 的输出]

请帮我分析：
1. 哪些 CVE 是高危/严重的？这些漏洞实际上能被利用吗（是否需要运行时接触）？
2. 哪些漏洞来自基础镜像，哪些来自我安装的依赖？
3. 修复建议：
   - 基础镜像升级：用哪个版本可以消除这些CVE？
   - 依赖升级：哪个包需要升级到什么版本？
4. 我应该优先修复哪些漏洞？（按实际风险排序，不是按CVSS分数）

额外：如何在 CI/CD 流程中集成 Trivy，在镜像含高危漏洞时让构建失败？

2.4 多阶段构建验收清单

检查项 验证方法 AI辅助
最终镜像不包含构建工具 `docker run --rm image sh -c "which gcc
基础镜像固定版本（无 latest） 检查 FROM 指令 用P02检查tag
前端构建利用层缓存 只改 src/ 代码，重新构建，npm install 应命中缓存 用P02检查COPY顺序
Go 使用静态编译 file main 命令应显示 statically linked 用P01检查CGO_ENABLED
定期安全扫描 docker scout cves IMAGE 或 trivy image IMAGE 无高危漏洞 用P03分析扫描结果

2.5 本章小结

如果你只记一件事：
多阶段构建的关键不只是"分两个stage"，还要：
Go → CGO_ENABLED=0 + -ldflags="-s -w" + distroless 基础镜像；
前端 → 先 COPY package.json，再 COPY 源代码，命中 npm install 缓存。

→ 第03章：AI帮我写了docker-compose，本地能跑，服务器为什么崩？