镜像体积优化核心是构建源头精简而非后期压缩，需选轻量基础镜像（alpine/distroless/scratch）、用多阶段构建分离编译与运行环境、精控上下文与层结构，并可选buildkit压缩分发。
镜像体积通过极限压缩降低存储成本，核心不是单纯“打zip包”，而是从构建源头剔除冗余、精简运行环境、控制上下文。真正有效的压缩是让最终镜像本身变小，而非后期压缩归档——后者只节省传输带宽，不减少 registry 中的存储占用。
选对基础镜像：5MB 能跑的服务，别用 200MB 的
基础镜像占最终体积的 60% 以上。Ubuntu、CentOS 等通用发行版包含大量调试工具、文档和非必要二进制文件，不适合生产部署：
-
Alpine Linux（约 5MB）：基于 musl libc 和 busybox，适合大多数 Go/Python/Node.js 应用；安装软件时务必加
--no-cache，避免 apk 缓存残留 - Distroless 镜像（2–6MB）：Google 提供的无 shell、无包管理器的极简镜像，仅含 CA 证书和运行时依赖，适用于 Java、Go、.NET 等静态或预编译语言
- scratch 镜像（0B）：仅适用于完全静态编译的二进制（如 Go 关闭 cgo 后构建），连 /bin/sh 都没有，安全性最高，但调试能力归零
多阶段构建：只留可执行文件，删掉整个编译链
传统单阶段构建会把编译器、源码、测试依赖全打进最终镜像。多阶段构建让构建环境和运行环境彻底隔离：
- 第一阶段用完整工具链（如
golang:1.21或node:20）完成编译、打包、测试 - 第二阶段用 Alpine 或 distroless 镜像，仅
COPY --from=builder复制产出物（如./main或dist/app.js） - 实测案例：Java Spring Boot 项目从 850MB → 95MB；Go Web 服务从 900MB → 12MB
精控构建上下文与层结构：少传一个文件，就少存一层缓存
Docker 构建时会把整个上下文目录（默认为 .）上传到构建引擎。哪怕 .git、node_modules、log/ 下的旧日志没被 COPY，也会影响构建传输体积和缓存命中率：
- 用
.dockerignore显式排除无关文件：.git、**/node_modules、*.log、docs/等 - 合并 RUN 指令减少镜像层数（每条 RUN 新增一层），例如：
RUN apt-get update && apt-get install -y curl jq && rm -rf /var/lib/apt/lists/* - 删除中间产物：安装软件后立即清理缓存，复制文件后删除临时解压目录
启用 Buildx + BuildKit 压缩输出（针对分发场景）
如果目标是降低镜像在 CI 流水线中传输或离线分发的成本，可结合 Buildx 输出压缩格式：
- 构建时指定
--output type=oci,dest=-,compression=gzip，直接生成image.tar.gz - 该方式不改变 registry 中的镜像大小，但能将推送/拉取流量压缩 40–60%，特别适合跨云、跨国同步
- 注意：需提前创建并启用支持 BuildKit 的构建器：
docker buildx create --name mybuilder --use && docker buildx inspect --bootstrap
