核心是通过镜像“做减法”和“提复用”直接降低部署总带宽：选最小可行基础镜像（如Alpine约5MB）、用多阶段构建剔除非运行时内容、在同一RUN中合并安装与清理、启用BuildKit优化层、配合私有仓库缓存与节点预热等分发策略，形成带宽治理闭环。
直接降低部署总带宽，核心是让每次拉取传输的数据量变少——镜像越小，单次传输耗带宽越低；镜像层复用率越高，重复传输越少。这不是靠压缩协议或提速网络，而是从镜像本体“做减法”和“提复用”。
选最小可行基础镜像
基础镜像占最终体积大头，选错一步，后续优化事倍功半。
- 优先用 Alpine（约5MB）替代 Ubuntu/Debian（70–100MB+），尤其适合 Go、Node.js、Python 等语言运行时
- 安全要求极高或无需 shell 调试的场景，直接用 distroless（如
gcr.io/distroless/nodejs），连包管理器和 shell 都不带 - 静态编译型应用（如 Rust、Go）可尝试
scratch镜像，体积常压到 10MB 以内 - 避免使用
:latest标签，改用语义化标签（如alpine:3.20），确保团队拉取的是同一层集合，提升缓存命中率
用好多阶段构建，剔除所有非运行时内容
构建工具、源码、测试文件、devDependencies、中间产物——它们只在构建时有用，绝不该进生产镜像。
- 第一阶段用完整环境（如
maven:3.9或node:18）完成编译/打包 - 第二阶段切换至精简镜像（如
alpine:3.20或distroless），仅COPY --from=builder复制产出物（如/app/dist、/target/*.jar） - Java 项目中，用
maven-dependency-plugin提前解压依赖并复制，避免把整个~/.m2打包进去 - Node.js 项目禁用
npm install，改用npm ci --only=production，跳过devDependencies
合并层、清理临时文件，减少冗余数据
Docker 层不是“覆盖删除”，而是“遮盖”。上层删文件，底层仍存在——必须在同一 RUN 指令里完成安装+清理。
- 把 apt/yum 更新、安装、清理写在一条 RUN 里：
RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/* - 避免多个独立 RUN：每个都会新增一层，且上层无法删除下层文件
- 构建时启用 BuildKit（
DOCKER_BUILDKIT=1），自动优化指令顺序和缓存 - 谨慎使用
docker build --squash（已弃用），推荐用 BuildKit + 多阶段天然实现层精简
配合分发策略，放大瘦身效果
再小的镜像，如果每次都在跨地域重复拉取，带宽压力仍在。瘦身必须和分发机制联动。
- 私有仓库（如 Harbor）开启代理缓存，首次拉取
nginx:alpine后，所有节点都走本地缓存 - 节点预热：滚动升级前，用
docker pull提前拉取高频镜像，避免 Pod 启动时集中触发拉取风暴 - 对超大镜像（如含 CUDA 的 PyTorch），转为 stargz 格式（
ctr-remote images convert --estargz），运行时按需加载文件，不强制全量下载 - Kubernetes 中设
imagePullPolicy: IfNotPresent，配合 CI 流水线自动推送到各集群边缘仓库
镜像瘦身不是一次性的构建技巧，而是贯穿开发、构建、分发、运行的带宽治理闭环。体积降下来，拉取快起来，集群扩容稳下来，安全面也收窄了——一招多得，但关键在坚持落地每一条精简逻辑。
