解读

国内面试官问这道题，核心想验证两点：

1. 你是否真的在生产镜像里踩过“构建依赖残留”带来的体积膨胀、攻击面扩大、合规扫描告警等坑；
2. 你是否能用多阶段构建把“编译时依赖”与“运行时依赖”彻底分离，并给出可落地的 Dockerfile 写法。
   回答时务必结合**国内镜像仓库（阿里云 ACR、腾讯云 TCR、华为云 SWR）**的“安全扫描扣分”场景，突出“镜像体积每减少 1 MB，跨省拉取时间就能减少 0.3 s”这一痛点，才能打动面试官。

知识点

1. 构建依赖残留的典型表现：
   • gcc、make、python-dev、npm、yarn、maven 等编译工具留在最终镜像；
   • 源码、.git、单元测试文件、临时缓存 一并打包；
   • 导致镜像 > 1 GB，安全扫描出现 CVE-2019-XXXX 高危告警，企业客户直接打回。
2. 多阶段构建关键语法：
   • FROM ... AS builder 阶段只负责编译；
   • COPY --from=builder 把编译产物精准拷贝到最终空白镜像；
   • 最终阶段使用 distroless 或官方 alpine 最小基础镜像，实现“零构建依赖”。
3. 国内加速技巧：
   • 在 builder 阶段先 RUN sed -i 's/dl-cdn.alpinelinux.org/mirrors.aliyun.com/g' /etc/apk/repositories，减少跨国下载；
   • 使用 ARG TARGETARCH 结合 docker buildx 做 amd64/arm64 双架构，适应国内信创 arm 节点。
4. 合规与审计：
   • 金融、政务云要求“最小化基础镜像”过等保 2.0，多阶段构建是唯一能在不改业务代码的前提下通过测评的手段。

答案

“构建依赖残留”是指编译阶段需要的 gcc、python-dev、node_modules、.git、测试用例 等文件在最终镜像里未被清理，导致镜像体积臃肿、攻击面扩大、安全扫描告警。
多阶段构建通过“一个 Dockerfile 内定义多个 FROM”把编译环境与运行环境彻底隔离：

1. 第一阶段 FROM maven:3.9-eclipse-temurin-17 AS builder 只负责 mvn package，产生的 /app/target/demo.jar 是唯一产物；
2. 第二阶段 FROM eclipse-temurin:17-jre-alpine 仅复制 jar 包：COPY --from=builder /app/target/demo.jar /app.jar；
3. 最终镜像里没有 maven、没有源码、没有 .git，体积从 1.2 GB 降到 118 MB，阿里云 ACR 安全扫描直接清零高危漏洞，跨省拉取时间缩短 70 %。
   这样即实现了“构建依赖零残留”，又满足国内云厂商对镜像最小化、合规化、双架构的硬性要求。

拓展思考

1. 当项目依赖 node-gyp、python、gcc 编译原生模块时，可以把 builder 阶段再拆成两层：
   • deps 阶段仅 npm ci --only=dev 装编译依赖；
   • builder 阶段再 npm run build；
     最终阶段用 node:18-alpine 并 npm ci --only=prod --ignore-scripts，彻底甩掉 python 与 gcc。
2. 国内金融客户要求“不可信第三方源”必须离线，可在 builder 阶段先 mvn dependency:go-offline，再把本地仓库打包成 tar.gz 走内网 Harbor，实现离线多阶段构建。
3. 结合 docker buildx --cache-to type=local,dest=/tmp/cache 做 GitLab CI 分布式缓存，北京、上海双机房共享同一层缓存，把 10 分钟编译降到 90 秒，这是国内大型券商容器化的真实案例。