选对基础镜像可缩减镜像体积一半以上，优先选用Alpine（5.5MB）、distroless-static（2.6MB）或scratch（0MB）；避免默认Debian系镜像，改用语言官方slim/alpine变体，并清理构建缓存与冗余文件。
基础镜像选对了，镜像体积就先砍掉一半以上。它不是起点，而是决定下限的关键——后续所有优化都建立在这个“地基”之上。
优先用 Alpine 或 distroless 镜像
Ubuntu、CentOS 这类通用发行版镜像自带大量系统工具、文档和调试组件，但绝大多数生产应用根本用不上。比如：
- ubuntu:22.04 约 73MB，适合需要完整 shell 和包管理的调试环境
- alpine:3.18 仅约 5.5MB，精简包管理（apk），无 systemd，适合 Go/Node/Python 等语言运行时
- distroless-static 约 2.6MB，不含 shell、包管理器或任何交互式工具，专为静态二进制设计，安全性更高
- scratch 0MB，真正空镜像，只适用于完全静态编译的程序（如 Go 关闭 cgo 后的二进制）
按语言匹配官方 slim/alpine 变体
别直接拉 python:3.11 或 node:20，它们默认基于 Debian，体积动辄 1GB+。应主动选用：
-
python:3.11-slim（约 130MB）比完整版小 60%+ -
node:20-alpine（约 120MB）比node:20（约 950MB）小近 90% -
openjdk:17-jre-slim或openjdk:17-jre-alpine，避免带完整 JDK 和调试工具的大镜像
警惕“看似轻量，实则臃肿”的陷阱
有些镜像标着 “slim”，但内部仍含 apt 缓存、未清理的构建依赖或冗余 locale。例如：
- 用
apt-get install后没加&& apt-get clean -y && rm -rf /var/lib/apt/lists/*，会多留 50MB+ - Alpine 上误装 glibc 兼容层（如
libc6-compat），反而破坏轻量优势 - Java 应用用了 JRE 镜像，却仍打包了 Tomcat 源码或示例 WAR 包——这些不该进最终镜像
验证基础镜像实际贡献
构建后执行：docker history your-image-name
看第一层（base image）占多少体积。如果它超过 100MB，大概率还能换更小的。
