docker镜像由按顺序堆叠的只读层构成，每层仅记录相对于上一层的文件系统变更；from、run、copy等指令各生成一层，unionfs合并为统一视图，容器运行时叠加可写层，删除操作不减少体积，多阶段构建可大幅瘦身。
docker 镜像不是一整块“大文件”，而是一组按顺序堆叠的只读层（layer），每一层只记录相对于上一层的文件系统变更。这种分层结构是镜像高效共享、快速构建和体积可控的根本原因。
分层机制如何实际工作
每条 Dockerfile 指令（如 FROM、RUN、COPY、ADD）都会生成一个新层。例如：
- FROM ubuntu:22.04 → 底层：完整基础 rootfs，约 70 MB
- RUN apt-get update && apt-get install -y curl → 新增层：仅包含 curl 及其依赖的新增/修改文件
- COPY app.py /app/ → 再新增一层：只存 app.py 文件本身
所有层通过 UnionFS（如 overlay2）合并为统一视图。容器启动时，Docker 在最顶层动态叠加一个可写层（Container Layer），运行时所有写操作（如日志、临时文件）都发生在此层，不污染底层只读层。
为什么分层直接影响镜像大小和构建速度
层是“只增不减”的——删除动作不会抹除旧层中的数据。比如：
- 拆成两行：
RUN apt-get install -y build-essential && rm -rf /var/lib/apt/lists/*→ 正确：清理与安装在同一层，缓存不落盘 - 写成两行：
RUN apt-get install -y build-essential+RUN rm -rf /var/lib/apt/lists/*→ 错误：第一层已存下几百 MB 缓存，第二层只是“标记删除”，体积照旧
构建缓存也基于层：只要某层指令及前置层未变，Docker 就复用该层缓存，跳过执行。因此，把变动频繁的指令（如 COPY 源码）尽量往后放，能大幅提升 CI 中的构建效率。
多阶段构建：精准控制最终镜像内容
单阶段构建常把编译工具、源码、中间产物全打进最终镜像，既臃肿又不安全。多阶段构建通过命名构建阶段，只在最后阶段 COPY 所需产物：
- 第一阶段（
builder）：基于golang:1.22，拉依赖、编译二进制 - 第二阶段（
final）：基于alpine:3.20，仅COPY --from=builder /app/server /usr/local/bin/
最终镜像不含 Go 编译器、源码、.git、node_modules 等任何构建期冗余，体积可从 1.2 GB 降至 15 MB 左右，攻击面大幅收窄。
调优落地的关键检查点
每次写完 Dockerfile，建议快速核对以下四点：
- 基础镜像是否最小化？优先选
alpine、distroless或官方 slim 版本 - 所有包管理缓存（apt lists、yum cache、pip cache、npm cache）是否与安装命令同层清理？
- 是否用多阶段分离构建环境与运行环境？Go/Java/Node.js 项目尤其必要
- 敏感信息（密钥、配置文件）是否通过构建参数或挂载注入，而非硬编码进镜像层？
这些不是“高级技巧”，而是生产环境中保障镜像轻量、安全、可复现的基本实践。
