一、为什么镜像会越来越大

很多 Docker 镜像变大的原因不是业务代码复杂，而是把构建环境、缓存、测试工具和运行时依赖全部塞进了最终镜像。一个 Node、Go 或 Java 项目在构建阶段需要编译器、包管理器和临时文件，但线上运行往往只需要二进制、静态资源或少量运行库。镜像越大，拉取越慢，漏洞扫描噪声越多，回滚和扩容也越慢。

二、多阶段构建的基本写法

多阶段构建的核心是把“构建”和“运行”拆成两个 stage。前一个 stage 安装依赖并产出制品，后一个 stage 只复制最终产物。下面是 Go 服务的常见写法：

FROM golang:1.22 AS builder
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o /out/app ./cmd/api

FROM gcr.io/distroless/static-debian12
WORKDIR /app
COPY --from=builder /out/app /app/app
USER 65532:65532
ENTRYPOINT ["/app/app"]

这里最终镜像没有 Go 编译器，也没有源码目录。COPY --from=builder 是关键，它让运行镜像只拿需要的文件。对于 Node 前端项目，同样可以用 node 阶段构建，再用 nginx 或静态服务器镜像承载 dist。

三、缓存与层顺序决定构建速度

优化体积时不要忽视构建速度。Docker 会按层缓存，依赖文件应该先复制，业务代码后复制。这样只改业务代码时，不会反复下载依赖。

FROM node:20-alpine AS deps
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci

FROM deps AS build
COPY . .
RUN npm run build

FROM nginx:1.27-alpine
COPY --from=build /app/dist /usr/share/nginx/html

还要配置 .dockerignore，避免把 node_modules、.git、测试报告和本地缓存发给 Docker daemon。上下文过大时，即使 Dockerfile 写得很好，构建也会慢。

.git
node_modules
coverage
dist
*.log

四、生产镜像的取舍

alpine 体积小，但 musl 与 glibc 差异可能影响某些二进制依赖。distroless 攻击面更小，但没有 shell，排障方式要依赖日志、探针和临时调试容器。团队应按语言栈和运维能力选择，而不是盲目追求最小。

实践上可以把镜像优化纳入 CI：构建后输出镜像大小，运行漏洞扫描，并启动容器做冒烟测试。合理目标不是把镜像压到极限，而是在可维护的前提下减少无用层、缩短发布链路、降低运行时风险。

还有一个容易忽略的点是基础镜像治理。团队应维护一组经过扫描和验证的基础镜像，统一时区、证书、用户权限和安全补丁，而不是让每个项目自由选择。构建参数也要谨慎使用，密钥不要通过 ARG 写进镜像层，临时凭证应依赖构建平台的 secret 能力。镜像优化最终要服务于交付：构建快、传输快、启动快、问题可定位，才是多阶段构建真正带来的收益。

如果镜像仍然偏大，可以用 docker history 查看每一层来源，再决定是调整复制范围、拆分依赖，还是更换运行时基础镜像。

📌 本文是《云原生工程实战》系列，持续更新，关注不迷路。
👉 下一篇：《Docker Compose编排微服务开发环境》，讲瘦身后的镜像如何组成可复现的本地服务栈。
💬 你在实际项目里遇到过 Docker 镜像层重复、依赖残留或构建时间过长的问题吗？评论区聊聊。
（觉得有用点个赞+收藏，方便回头查阅）
🔧 相关可运行源码/资料已整理成资源包，可在我主页的资源里自取。