多阶段构建本质是隔离手段而非清洗工具，关键在于严格划分构建阶段、精确控制copy--from路径、禁用明文密钥注入，配合buildkit secret机制确保密钥不进入任何镜像层。
多阶段构建本身不是“清洗工具”，而是隔离手段。真正能防止密钥残留的，是配合构建阶段划分、严格控制文件传递路径、禁用不安全注入方式的一整套操作逻辑。关键不在“删”，而在“不带进去”。
禁止在构建阶段写入或暴露密钥
敏感信息绝不能出现在任何构建阶段的镜像层中——哪怕只存在一秒，也会固化进历史层，被 docker history 或 dive 提取出来。
- 删除
ENV SECRET_TOKEN=xxx和ARG API_KEY这类明文声明，它们会直接写入镜像元数据 - 避免
RUN echo "DB_PASS=123" > .env或COPY config-with-key.yaml .等操作 - 不要依赖“后续
RUN rm -f .env”来“清理”，该文件内容仍保留在前一层中
用 BuildKit 原生 secret 替代环境变量传参
Docker 27 默认启用 BuildKit 后，可安全地将密钥仅用于构建过程，且完全不进入镜像层。
- 构建时通过
--secret id=mykey,src=./prod.key挂载密钥文件 - 在 Dockerfile 中用
RUN --mount=type=secret,id=mykey ...让构建命令临时读取 - 该 secret 不会出现在任何镜像层、不记录在构建日志（默认）、不暴露给运行时
精确控制 COPY --from 的文件范围
多阶段的核心价值在于“只拿需要的，不带多余的”。中间构建阶段可能含密钥配置或调试工具，必须杜绝误复制。
- 始终使用命名阶段（如
FROM golang:1.21 AS builder），而非隐式0、1 - 用
COPY --from=builder /app/dist/app.bin .，而不是COPY --from=builder /app . - 检查中间阶段是否意外包含
.git、node_modules、secrets/目录，用.dockerignore提前排除
交付前强制扫描与验证
自动化验证比人工检查更可靠。把扫描嵌入构建流程，作为出口守门员。
- 启用 BuildKit 内置 Trivy 扫描：
docker build --output type=image,push=true --secret id=trivy,src=/dev/null .（需配置） - 或在构建后立即执行：
trivy image --severity CRITICAL,HIGH myapp:v2 - 重点检测：硬编码密钥（正则匹配）、常见密钥文件（
id_rsa、.env、config.json）、非预期的证书路径
