选对基础镜像、多阶段构建、精确copy、单层清理依赖、用.dockerignore过滤、验证真实体积，六步可将1.8gb镜像压至180mb甚至35mb。
想把 docker 镜像从 1.8gb 压到 180mb，甚至压进 35mb，不是靠玄学，而是靠几条清晰、可验证、能落地的路径。核心就一句话：只留运行必需，其余全砍。
选对基础镜像，直接砍掉一半体积
基础镜像不是越大越稳，而是越精越快。官方 openjdk:17-jdk 动辄 700MB+，但生产环境根本用不到编译器和调试工具；node:20 自带完整 npm、gcc、make，而你只需要一个 node dist/server.js。
- Java 服务优先用
eclipse-temurin:17-jre-jammy或amazoncorretto:17-jre-alpine，比 full JDK 小 60% 以上 - Node 项目改用
node:20-alpine，体积从 900MB+ 降到 120MB 左右 - Go/Rust 程序禁用 cgo 后，直接上
FROM scratch，最终镜像就是二进制本身，0 层额外依赖 - 避免使用
ubuntu:22.04或centos:7这类通用发行版镜像，除非你真需要它们的包管理或兼容性
必须用多阶段构建，把“编译现场”和“运行现场”彻底分开
单阶段构建等于把整个厨房搬进餐厅——Maven、JDK、node_modules、.m2 缓存、临时构建产物，全塞在一个镜像里。多阶段不是高级技巧，是生产级项目的标配。
- 第一阶段（builder）用完整工具链：
FROM maven:3.8-openjdk-17 AS builder，只做下载依赖、编译、打包 - 第二阶段（runtime）换轻量镜像：
FROM eclipse-temurin:17-jre-jammy，只 COPY 第一阶段生成的 jar 或二进制 - 前端项目同理：用
node:20构建，再 COPYdist/到nginx:alpine或httpd:alpine中 - 注意 COPY 要精确到文件，别写
COPY --from=builder /app/target/*.jar .，避免把测试包、SNAPSHOT 版本一起拷进去
每一层都要算账，删不掉的就别让它进来
Docker 镜像是层叠结构，RUN rm -rf /var/lib/apt/lists/* 不会减小镜像体积，因为删除操作只是在上层加了个“掩码”。真正瘦身，得让那些大文件根本不出现在某一层里。
- apt 安装后立刻清理：
RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/*写在同一行 RUN 里 - npm 安装时跳过 devDependencies：
RUN npm ci --only=production，比npm install少载几百 MB - 用
.dockerignore过滤掉node_modules/、.git/、docs/、tests/等非运行必需目录 - 检查层体积：执行
docker history your-image-name，重点关注 SIZE 列，哪一层超 200MB 就重点优化哪一层
验证是否真瘦了，不能只看 docker images
docker images 显示的是本地缓存的镜像大小，可能包含中间层或旧标签。要确认真实交付体积，得看推送到仓库后的实际拉取大小。
- 推送到私有 registry 后，用
curl -X GET "https://your-registry/v2/your-app/manifests/latest" -H "Accept: application/vnd.docker.distribution.manifest.v2+json"查 manifest - 用
docker save your-image | gzip | wc -c模拟网络传输体积（即 tar.gz 后大小），这个更贴近 CI/CD 和生产拉取场景 - 对比优化前后冷启动耗时：
time docker run --rm your-image echo ok，体积小通常意味着解压快、挂载快、进程启动快 - 定期跑
docker system df -v，观察构建缓存是否被有效复用，避免因指令顺序错乱导致缓存失效、反复重下依赖
