容器镜像瘦身：多阶段构建与分层缓存的实用做法

一个 Web 服务的镜像从 80MB 膨胀到 800MB，往往不是一夜之间发生的。每次构建多装一个工具、多留一份源码、多复制一层依赖，体积就悄悄涨一点。等到拉取变慢、部署超时、存储账单变高时，才回头去翻 Dockerfile。本文用一个常见的 Web 服务为例，讲三招最实用的瘦身做法：多阶段构建、分层缓存和基础镜像取舍。

为什么镜像会越做越大

镜像体积主要来自三个地方。第一是构建工具链：编译器、调试工具、测试依赖在运行期完全用不到，却被一起打进了最终镜像。第二是中间产物：源码、构建缓存、临时文件如果没有清理，都会以独立层的形式留下来。第三是基础镜像本身：一个带完整工具链的系统镜像起步就几百 MB，后面再怎么省也省不回来。

判断体积来源最直接的办法，是分层查看镜像。哪一层突然变大，就先处理哪一层。很多时候罪魁祸首不是业务代码，而是一条被遗忘的复制命令。

多阶段构建：编译与运行分开

多阶段构建的核心思想很简单：用一个阶段做构建，用另一个阶段做运行，最终镜像只保留运行必需的东西。

以一个需要编译的 Web 服务为例，第一阶段使用带完整工具链的基础镜像，完成依赖安装和编译，产出可执行文件和静态资源；第二阶段换成精简的运行镜像，只从第一阶段复制可执行文件、配置文件和静态资源，不复制源码、不复制工具链、不复制构建缓存。

这样做的好处不只是体积小。运行镜像里没有编译器和调试工具，攻击面也随之变小；镜像内容更干净，出问题时更容易定位是运行环境还是业务代码的问题。需要注意的是，两个阶段之间只复制明确列出的产物，不要图省事把整个工作目录拷过去，否则瘦身效果会大打折扣。

分层缓存：把变化慢的放前面

Docker 的分层缓存规则是：某一层变了，它之后的所有层都要重新构建。因此 Dockerfile 里指令的顺序，直接决定了构建速度和缓存命中率。

实用的排序原则是把变化慢的放前面、变化快的放后面。具体做法是：先复制依赖描述文件，再安装依赖；然后复制源码，最后执行构建。这样一来，日常改业务代码时，依赖安装层可以直接复用缓存，只有后面的源码层和构建层需要重跑。

还有两个常见坑值得避开。一是不要在安装依赖之前就复制全部源码，否则每次改一行代码都会让依赖层失效。二是避免把经常变动的文件和依赖安装写在同一层，例如把配置文件和依赖安装混在一起，会让缓存频繁失效。

基础镜像的选择与取舍

基础镜像不是越小越好，要在体积、兼容性和可维护性之间取舍。精简镜像体积小、启动快，但可能缺少常用的调试工具和系统库，遇到依赖缺失时排查会更费劲。完整系统镜像开箱即用，但体积大、补丁面广。

一个稳妥的做法是：先按运行时的真实依赖选镜像，而不是按开发习惯选。如果服务只需要运行一个静态编译的可执行文件，精简镜像完全够用；如果服务依赖动态库、时区数据或证书链，就要确认这些内容在精简镜像里是否存在，缺失的要在 Dockerfile 里显式补齐并写进文档。

另外，基础镜像要固定版本标签，不要长期使用 latest。固定版本能保证不同时间构建出的镜像行为一致，出问题时也更容易回滚和复现。

容易忽略的清理细节

除了大方向，还有几处小地方经常被忽略。构建过程中产生的临时文件、包管理器的缓存目录、测试报告和日志，都应该在同一层里及时清理；分开写成两层是没有用的，因为已提交的层不会因为后面删除文件而变小。

日志和数据目录也不要打进镜像。日志应该在运行时挂载或输出到标准输出，数据应该走外部存储。把运行期才会产生的文件提前放进镜像，只会让镜像越来越臃肿。

最后，定期检查不再使用的镜像和悬空层。开发机器和构建节点上堆积的旧镜像不会影响线上体积，但会拖慢构建和排查速度，定期清理是个好习惯。

一份可直接套用的检查清单

发布前可以按这份清单过一遍：构建与运行是否分阶段，运行镜像里是否只剩必需产物；依赖安装层是否排在源码复制之前，缓存是否能正常命中；基础镜像版本是否固定，缺失的系统库是否已显式补齐；临时文件和包管理器缓存是否在同一层清理干净；日志和数据是否没有打进镜像。五项都通过，镜像体积通常能控制在一个合理范围。

结语

镜像瘦身没有银弹，靠的是一组可重复的习惯：阶段分开、顺序排对、基础镜像选对、清理做在同一层。把这套做法固定成团队的模板和检查清单，新服务一开始就不会走偏，老服务改造时也有章可循。镜像小了，拉取更快、部署更稳、排查也更轻松，这笔账长期看非常划算。