Docker 镜像分层原理与瘦身如何做

Docker镜像通过分层结构实现复用，瘦身关键在于减少层数、清理中间产物、选用轻量基础镜像及多阶段构建。

Docker 镜像不是一整块“硬盘镜像”，而是一层层堆叠起来的只读快照。理解分层，才能真正把镜像变小——不是删文件，而是从构建逻辑上减少冗余层和残留内容。

分层结构怎么来的

每条 Dockerfile 指令（FROM、RUN、COPY、ENV 等）都会生成一个新层。比如：

1. FROM alpine:3.18 → 基础层（约 5MB）
2. RUN apk add --no-cache curl → 新增一层，只记录 curl 及其依赖的变化
3. COPY app.py /app/ → 再加一层，仅包含这个文件

这些层通过内容哈希唯一标识，相同层在不同镜像间自动复用。但层越多、单层越臃肿，整体体积就越大。

瘦身关键：控制层数 + 清理中间产物

很多镜像变大，不是因为应用本身重，而是构建过程把临时文件、包管理缓存、编译工具全打包进去了。重点做三件事：

1. 把多个 RUN 命令合并成一条，避免产生多余层（如 RUN apt update && apt install -y nginx && apt clean）
2. 所有包管理器加 --no-cache 参数（apk、apt、pip、npm 都支持），跳过本地缓存生成
3. 手动清理残留目录：apt 的 /var/lib/apt/lists/、apk 的 /var/cache/apk/、npm 的 node_modules/.cache

用对基础镜像，直接砍掉一半体积

ubuntu:latest（77MB）、centos:stream（200MB+）这类完整发行版，运行一个 Python Web 服务纯属浪费。换成更合适的：

1. Alpine Linux（5MB 左右）：轻量、安全，默认用 musl libc，适合大多数语言运行时
2. -slim 变体（如 node:20-slim、python:3.11-slim）：基于 Debian，比 full 版精简 60%+，兼容性更好
3. -alpine 或 -distroless：distroless 镜像甚至不带 shell，只含运行时依赖，安全性最高

多阶段构建：彻底分离编译环境和运行环境

这是最有效的瘦身手段。例如 Go 或 Java 应用需要编译，但运行时根本不需要 go 编译器或 JDK：

1. 第一阶段用 golang:1.23 编译出二进制文件
2. 第二阶段用 alpine:3.18 或 scratch，只 COPY 编译好的可执行文件
3. 最终镜像里只有二进制 + 动态库（或全静态链接），体积常压到 10–30MB

Node.js、Rust、.NET 项目同样适用——编译工具链完全不进最终镜像。