Docker 镜像瘦身，在多阶段构建普及前我常做的四件事

现在大家一提 Docker 镜像优化，很容易先想到多阶段构建。但 2017 年那会儿，很多团队日常还没有把这套玩法完全用顺。想让镜像体积别太夸张，往往还是靠一些更基础、也更朴素的习惯。

我那时最常做的，不是追求极限压缩，而是先把明显浪费的地方收掉。

第一件事：别把无关文件一起打进上下文

构建目录里如果把日志、文档、测试产物、编辑器配置甚至 node_modules 全带进去，镜像从第一层开始就已经重了。
这类问题最冤，因为它不是业务必须，而是打包边界没控制住。

我后来会更在意构建上下文里到底进了什么，而不是只盯最终结果。

第二件事：把变化频率不同的步骤拆开

镜像构建慢和镜像过大，经常是一起出现的。
如果依赖安装、代码拷贝、配置生成全部揉成一层，每次改一点业务代码都要让前面的大步骤重新失效，缓存就帮不上忙。

即使在没有多阶段构建的前提下，把变化慢的依赖层和变化快的业务层尽量分开，收益也很明显。

第三件事：运行时只保留真正会用到的东西

很多镜像默认会把构建期才需要的工具、压缩包、临时文件、调试脚本也一起留在里面。
这不只是体积问题，还会把镜像内容越堆越杂。

我后来更喜欢在构建过程中就顺手清掉临时产物，让运行时镜像尽量只承载“启动程序需要的那部分”。

第四件事：不要为了省事放弃层次感

有些人会把很多命令硬塞进一条长长的 RUN 里，觉得这样层少。
但如果这让可读性变差、调试困难、缓存策略也没想清楚，最终并不一定是好事。

镜像优化不是只看层数，而是看每一层是不是表达了合理边界。

如果今天回头看

后来多阶段构建成熟之后，很多事情确实优雅了不少。
但我现在反而更确定，真正有价值的不是某一种技巧，而是那套“哪些文件该进来、哪些步骤该分开、哪些东西不该留到运行时”的意识。

这套意识在 2017 年就值得建立了，到了今天也没过时。