多阶段构建能移除编译环境风险，因其仅将编译产物复制至最终镜像，彻底排除gcc、go、npm、源码、node_modules等构建依赖；docker官方统计可减少90% cve暴露面。
为什么 multi-stage 构建能移除编译环境风险
因为最终镜像里根本不会存在 gcc、go、npm、源码、node_modules 或构建缓存——这些只存在于中间构建阶段，而 COPY --from=builder 之后的运行阶段镜像，连 /bin/sh 都可以没有。Docker 官方统计显示，这样能减少 90% 的 CVE 暴露面。
Go 应用中必须禁用 CGO 并使用静态链接
否则二进制会动态依赖 libc，导致在 alpine 或 distroless 镜像中直接报错：standard_init_linux.go:228: exec user process caused: no such file or directory（本质是找不到动态链接器）。
-
CGO_ENABLED=0是硬性要求，尤其当你用gcr.io/distroless/static-debian11或scratch - 加上
GOOS=linux和GOARCH=amd64（或arm64）确保交叉编译正确 - 示例命令：
CGO_ENABLED=0 GOOS=linux go build -a -ldflags '-extldflags "-static"' -o app .
FROM 后缀选错会让整个多阶段失效
比如写 FROM golang:1.21 没问题，但运行阶段若写成 FROM node:18，就又把 npm、yarn、/usr/local/bin/node 全带进去了——这不是“精简”，是“换了个胖法”。
- Go/Rust/C 二进制：优先选
gcr.io/distroless/static-debian11（无 shell、无包管理器）或scratch（真正空镜像，需确认二进制完全静态） - Node.js 运行时：必须用
node:18-alpine或node:18-slim，禁用node:18（含完整 Debian + build-essential） - Java 应用：别用
openjdk:17-jdk，改用openjdk:17-jre-slim或解压后只取dependencies/和application/
COPY --from 阶段名必须精确匹配 AS 别名
常见错误是拼错阶段名，比如写了 FROM golang:1.21 AS builder，但复制时写成 COPY --from=build（少个 r），结果 Docker 会静默 fallback 到本地文件系统复制，把整个构建目录拖进运行镜像，前功尽弃。
- 阶段名区分大小写，
AS Builder和--from=builder不匹配 - 不建议省略
AS别名，直接用数字索引（如--from=0）可读性差且易错位 - 可以用
docker build --target builder -t myapp:build .单独调试构建阶段输出
RUN apk add 或 RUN apt-get install，就等于主动把攻击面打了开来**。distroless 镜像不是“更安全的 Linux”，而是“没有 Linux 工具链的运行载体”——它的安全收益，全靠你管住手，不往里塞任何运行时不需要的东西。
