本文教你如何用 Docker 多阶段构建把镜像从动辄上 GB 瘦身到几十 MB，解决构建慢、推送慢、攻击面大三个核心问题。读完你能拿到 Go、Node、Python 三类典型项目的 Dockerfile 模板，以及 .dockerignore 与基础镜像选型的判断清单，帮助你把流水线的构建时长压缩一半以上，让生产部署变得更快更稳。
一、为什么镜像越做越大
很多团队第一版镜像动辄一点五个 GB，根本原因是把构建工具链和运行时打在了同一层。一个 Go 项目可能只需要一个十几兆的静态二进制，却拖了一个八百多兆的 golang 完整镜像；Node 项目把开发依赖也带进了运行镜像；Python 把 pip 缓存与编译器统统留在了最终层。镜像太大不仅推送慢、拉取慢，攻击面也跟着变大，每个用不到的二进制都是潜在的漏洞入口。
镜像瘦身的核心思路其实就一句话：构建产物与构建工具分离。多阶段构建就是为此设计的功能，可以在第一阶段用大镜像编译，然后在第二阶段只复制最终产物到精简镜像里。再配合 .dockerignore 把无关文件排除在构建上下文之外，构建速度还能再上一档，层缓存命中率也会更高。
二、多阶段构建的基本骨架
多阶段构建在 Dockerfile 里用多个 FROM 指令实现，每个 FROM 开启一个新的 stage，可以用 AS 关键字起别名，后续 stage 用 COPY 从前一阶段拿产物。最常见的两阶段模板就是 builder 加上 runtime：第一段用完整开发镜像编译，第二段换成最小基础镜像运行。
生产环境推荐总是给 stage 起别名，避免后面插入新 stage 时索引错位。结构复杂的项目还可以拆出 deps、builder、test、runtime 四个段，把依赖下载与代码编译分开，让层缓存命中率达到最大。如果还在为节点选型烦恼，可以参考 美国 VPS 部署教程 了解部署流程。
三、Go、Node、Python 三类模板
Go 是多阶段构建受益最大的语言。第一段用 golang alpine 跑编译，第二段换 distroless static 只复制二进制。实测一个十五兆的 Go 程序，最终镜像大约二十兆，比直接用 golang alpine 整包减少 95%。Node 项目推荐三段式：deps 段装生产依赖，builder 段装全部依赖跑 build，runtime 段从两段分别取 node_modules 与 dist。Next 项目记得开启 standalone 输出模式，让框架自动打包最小依赖树。
Python 没有静态编译，但虚拟环境可以当作产物复制。builder 段装好编译器，runtime 段只复制装好的包目录。Alpine 在 Python 上反而是个坑，musl libc 与 manylinux wheel 不兼容会触发源码编译，最终镜像反而更大，建议直接用 slim 镜像。三类语言的共同心法是依赖在前、源码在后，最大化利用 Docker 的层缓存。
四、.dockerignore 的常见漏配
.dockerignore 的作用相当于 .gitignore，决定哪些文件不进构建上下文。漏配的代价是构建慢加镜像泄密，影响很大。
- 至少要包含 .git、node_modules、.venv、pycache、coverage、dist、build
- 排除 .env、.env.local 等凭据文件，避免被 COPY 带进镜像层
- 排除 markdown 文档、tests、.github 等运行时不需要的目录
- 排除 Dockerfile 与 docker-compose.yml，减少缓存失效
- 用感叹号语法保留个别必要文件，如 README 用于版本说明
镜像里万一被 COPY 进了 .env，攻击者只要 pull 就能拿到生产凭据，这是国内外都很常见的事故。建议每个仓库把 .dockerignore 视作必备文件一起维护。SSH 与服务器基础加固内容可参考 SSH Fail2ban 加固实战，把暴露面进一步收窄。
五、基础镜像选型与 BuildKit
镜像底座选什么直接决定瘦身的天花板。常见选项从大到小依次是：ubuntu 八十兆、debian slim 三十兆、alpine 八兆、distroless static 两兆、scratch 零兆。Alpine 用 musl libc，部分原生模块兼容性差；distroless 没有 shell，攻击面最小但调试不友好。推荐 Go 用 distroless，Node 与 Python 用对应官方 slim 镜像。
打开 BuildKit 让构建并行化，环境变量 DOCKER_BUILDKIT 设为一，或者直接用 buildx 命令。BuildKit 支持挂载 type 为 cache 把 pip、npm、go mod 的下载缓存挂到宿主机，下次构建不用重下。层顺序也很关键，要把改动频率低的指令放上面，COPY package.json 与 npm ci 应该在 COPY 源码之前，否则改一行业务代码就要重装全部依赖。
六、安全扫描与流水线整合
镜像瘦下来不等于就安全了，建议把 trivy、grype 这类扫描器集成进 CI，每次推送前扫一次漏洞，高危直接卡住合并。生产镜像还可以用 cosign 做签名，部署侧用 admission controller 校验签名，防止镜像被替换。禁用 latest 这种漂移标签，必须用 commit sha 或 semver 这类不可变标签，并在注册中心打开不可变策略，从根上阻止覆盖。要给 Registry 做 CDN 加速可参考 Cloudflare CDN 中国加速，进一步压缩拉取耗时。
流水线推荐这样配置：PR 阶段只构建到 test stage 跑单元测试；合并到 main 后用 buildx 出多架构镜像；用 cache-to 与 cache-from 把缓存推到 registry。整套跑下来，一个中型 Node 项目镜像构建时长能从十分钟压到两分钟，体积从一点二 GB 压到一百八十兆左右。
总结与建议
建议每个团队都先把多阶段构建与 .dockerignore 这两件事做透，这是性价比最高的两项优化。可以先在测试项目里跑通流程，再推广到所有仓库，把 Dockerfile 模板沉淀成内部脚手架让新项目零成本接入。如果你需要稳定节点托管 Registry 与缓存，可以考虑选用合适的服务器方案做镜像中转，并配合 WordPress 缓存调优 这类链路优化思路一起做整体提速。把构建产物与工具链分离、用 .dockerignore 严格控制上下文、按语言选合适的基础镜像，这三步做完镜像通常能瘦下八成以上，构建与发布的体验也会有质的提升。