镜像体积直接影响容器冷启动性能，优化需围绕减少传输量、加速层挂载、降低运行时开销三线并进：选轻量基础镜像（如Alpine约5MB、distroless或scratch）、用多阶段构建剥离编译环境、合并RUN指令并清理缓存、借助Dive工具分析层浪费。
镜像体积直接影响容器冷启动时的加载性能——体积越小，下载越快、挂载层越少、联合文件系统初始化越轻量。优化不是单纯删文件，而是围绕“减少传输量 + 加速层挂载 + 降低运行时开销”三线并进。
选对基础镜像，从源头压体积
基础镜像占最终镜像体积的 50% 以上。Ubuntu 或 CentOS 镜像动辄 200–300 MB，而 Alpine Linux 仅约 5 MB，distroless 镜像甚至接近 0 MB（仅含运行时依赖）。
- Java 应用优先用
openjdk:17-jre-slim或gcr.io/distroless/java17，避免openjdk:17-jdk带编译器和调试工具 - Go/Rust 等静态编译语言可直接基于
scratch，确保二进制无动态链接依赖（如 Go 编译加CGO_ENABLED=0） - 慎用“官方推荐但未精简”的镜像，例如
node:18比node:18-alpine大 4 倍以上
用好多阶段构建，剥离构建时污染
传统单阶段构建会把 npm install、mvn compile、源码、测试工具等全打包进最终镜像，造成大量冗余层和体积浪费。
- 第一阶段用完整工具链镜像（如
maven:3.9-openjdk-17）编译打包 - 第二阶段切换至极简运行镜像（如
openjdk:17-jre-slim），只COPY --from=0复制产出的 jar 或二进制 - 合并 RUN 指令减少层数，例如
RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/*
精简层内容与结构，提升挂载效率
容器启动时，Docker 要按序挂载所有只读层到 OverlayFS。层数越多、每层内无效文件越多，挂载耗时越长，且缓存复用率越低。
- 删除构建中间产物：
RUN npm ci --only=production && npm prune --production，清掉devDependencies - 清理包管理器缓存：
apk --no-cache add（Alpine）、apt-get clean && rm -rf /var/lib/apt/lists/*（Debian） - 避免同一文件在多层中“先增后删”，比如
COPY src/ .后又RUN rm -f debug.log—— 这类操作仍会保留在某一层中，应前置清理或用 .dockerignore 排除
借助工具定位浪费，让优化有据可依
凭经验删文件容易遗漏，也难评估收益。Dive 是最实用的镜像分层分析工具，能直观显示每层大小、文件变化和空间浪费点。
- 运行
dive your-image:tag，左侧看层叠结构，右侧查某层具体文件 - 关注 “Waste” 列和底部 “Image Efficiency” 得分，低于 80% 说明存在明显冗余（如重复拷贝、未清理的临时目录）
- 结合
docker history --no-trunc your-image:tag查哪条指令引入了大层，针对性重构 Dockerfile
