技能介绍

镜像膨胀时，真正该问的问题

一个 1GB 的镜像意味着什么？更慢的部署、更慢的扩容、更大的攻击面，以及按 GB 计费的存储账单。多数团队的镜像并不是业务代码大，而是构建环境、依赖缓存、甚至 .git 目录被整个 COPY 进了镜像。这篇指南假设一个前提：镜像体积不是虚荣指标，而且大多数镜像可以在不改一行业务代码的前提下瘦身 50–90%。

它如何工作

这个技能扮演「镜像优化教练」，流程分为三步：

先诊断，再动手：镜像是只读层的堆叠，上层删除下层文件不会减小体积——这是 90% 的「我明明删了怎么还这么大」的答案。用 dive 或 docker history 逐层定位新增文件与浪费率，三大元凶通常是包管理器缓存、遗留的构建工具链、以及误 COPY 的 .git/node_modules/测试数据。
按收益排序的六招：多阶段构建收益最大（编译型语言可从 1GB 降到几十 MB）；基础镜像从全量发行版逐级换到 slim/alpine/distroless；下载与清理必须写在同一条 RUN 里；只装生产依赖；配好 .dockerignore；对二进制 strip、前端只留 dist。
提速与安全并行：把变化频率低的指令放前面，用 BuildKit 的 cache mount 复用包管理器缓存，CI 里显式导入导出构建缓存。安全基线方面，非 root 运行、扫描进 CI、固定版本标签而非 latest、用 BuildKit secret 挂载密钥、运行镜像里不留 curl/bash/包管理器。

适用边界与注意点

瘦身与可调试性存在权衡：distroless 镜像进不去 shell，需要配套 debug 变体或临时容器调试方案。alpine 的 musl 在部分 Python/Node 原生依赖上有兼容性坑。文末的体积参考区间（Go/Rust <50MB、Node <200MB、Python <300MB、JVM <300MB）应结合语言栈与运行时使用，而不是当作硬指标。BuildKit 特性仍在演进，具体语法以 Docker 官方最新文档为准。