镜像构建与缓存机制归纳总结

说实话，Docker镜像构建这件事，很多人把它想得太简单了。不就是写个Dockerfile然后docker build嘛？但实际维护过生产镜像的人都知道——构建速度、缓存命中率、镜像大小，每一个都能让你头大。我见过团队为了省几秒构建时间，把RUN apt-get update和apt-get install拆开写，结果缓存没用好反而更慢。这一章我们就系统梳理一下镜像构建的底层逻辑和缓存机制，把那些“玄学”变成可理解、可预测的东西。

Docker构建的核心流程

当你执行docker build时，Docker引擎会做这三件事：

1. 读取Dockerfile — 逐行解析，每一条指令对应一个中间层。
2. 发送构建上下文 — 将当前目录（或指定路径）压缩打包发给Docker daemon。
3. 逐层执行并缓存 — 如果某层命中缓存，直接复用；否则执行指令，生成新层。

嗯，这里要注意：构建上下文里不要塞无关文件。我之前有个同事，把整个node_modules都放进了上下文，每次构建都要传几百MB的压缩包，速度慢得让人怀疑人生。解决办法很简单——用好.dockerignore。

分层缓存：Docker的“懒加载”哲学

Docker镜像是由只读层堆叠起来的。每一层对应Dockerfile的一条指令。缓存机制说白了就是：如果当前层的输入（命令哈希、上下文文件哈希）和上一层的镜像ID都一样，就重用这一层，不再重新执行。

为什么会这样设计？你想想看，大部分开发场景下，代码改来改去，但基础包、系统依赖很少变。分层缓存让我们能“只重编改过的层”，大大加速迭代。

但这里有个坑——层与层之间有顺序依赖。一旦前面某一层变了，后面的所有层都会失效。我教你一个原则：

• 把不常变的东西放在Dockerfile前面。
• 把经常变的东西放在最后。

举个例子，常见的最佳实践：

FROM python:3.11-slim AS builder

# 系统依赖——几乎不变
RUN apt-get update && apt-get install -y --no-install-recommends \
    build-essential libffi-dev \
    && rm -rf /var/lib/apt/lists/*

# Python依赖——按requirements.txt变更
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# 应用代码——最常变
COPY . .
CMD ["python", "app.py"]

这样写，只要requirements.txt没变，pip install那层就能命中缓存。代码改了，只重跑最后两步，快得很。

缓存失效的条件

缓存不是一直有效的。Docker通过比较以下内容来判断是否命中：

指令类型	缓存匹配依据	常见失效场景
FROM	基础镜像ID	本地没有该tag的基础镜像，或基础镜像被更新
RUN	命令字符串	命令本身改变（注意包含变量展开后的值）
COPY/ADD	源文件校验哈希	文件内容、权限、时间戳变化（ADD还会看压缩包哈希）
ENV/ARG	键值对	值改变（ARG的默认值不算，但构建时传递的--build-arg会影响）

简单来说：凡是你写死在Dockerfile里的东西变，才可能命中缓存；动态传入的参数（比如日期、随机数）会让缓存永远不命中。

如何高效利用缓存——实战策略

基于上面的原理，我整理了几条实战中特别有效的缓存利用策略：

1. 合理排序指令 — 最稳定的指令放最前面（FROM、LABEL、ENV、RUN apt），最易变的放最后（COPY源码、RUN测试）。
2. 合并RUN命令 — 把apt-get update和apt-get install放同一条命令，避免缓存了过期的update层导致后续安装失败。
3. 利用--cache-from — CI/CD中经常用，从之前的构建产物中拉取缓存层。比如Jenkins里可以docker pull myapp:latest然后构建时指定--cache-from myapp:latest。
4. 多阶段构建中的缓存 — 每个FROM是独立的缓存空间。第一阶段（构建阶段）的缓存不影响第二阶段（运行阶段）。

多阶段构建与缓存的关系

多阶段构建是Docker 17.05+引入的强大特性。它的本质是：在一个Dockerfile里写多个FROM，每个阶段可以有自己的基础镜像，最后只保留必要的产物到最终镜像中。缓存机制在各阶段内部独立工作。举个例子：

# 第一阶段：编译
FROM golang:1.21 AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -o server .

# 第二阶段：运行
FROM alpine:3.19
COPY --from=builder /app/server /server
CMD ["/server"]

第一个FROM的缓存只影响builder阶段；第二个FROM（alpine）的缓存独立。如果你只改了main.go，builder阶段的COPY . .和后续层失效，但COPY go.mod go.sum和RUN go mod download还是命中的。alpine阶段只有一个COPY --from操作，它会缓存最终产物的哈希，如果server二进制没变（比如只改了测试代码没影响编译产物），也能命中。

这样做的好处有两个：最终镜像很小（只包含二进制和运行环境），而且缓存粒度更细。

知识体系总览

缓存与构建上下文的关系

很多人忽略了一个点：COPY指令会校验整个构建上下文中的文件，而不仅仅是Dockerfile中COPY的那个具体路径。如果你在上下文中不小心放了大量无关文件，它们的校验和变化会影响缓存命中吗？不会。Docker只计算被COPY或ADD指令实际引用的文件的哈希，其他文件不影响缓存。但是这些无关文件仍然会增加上下文传输时间。所以还是那句话：.dockerignore 一定要写好。

实际案例：优化CI构建时间

我去年在一个微服务项目里，CI构建时间平均要7分钟，开发体验很差。分析后发现两个问题：

• Dockerfile里RUN pip install放在了COPY . .之后，每次改任何文件都会重装所有Python包。
• 构建上下文包含了.git和tests/下的大文件，传输就花了30秒。

调整方案很简单：

1. 把COPY requirements.txt提前，单独一层安装依赖。
2. 在.dockerignore里加上.git、__pycache__、*.pyc、tests/*.log。
3. 对构建阶段增加--cache-from，引入上一次构建的镜像作为缓存源。

改完后构建时间直接降到1分20秒，缓存命中率稳定在85%以上。嗯，优化前后差异巨大，值得你花10分钟检查一下自己的Dockerfile顺序。

总结

缓存机制并不复杂，核心就是“层序固定、输入稳定、分层复用”。只要记住：稳定的排在前面，易变的排在后面；构建上下文尽量小；小心--build-arg和ADD的自动解压行为。按照这些原则写Dockerfile，你的构建会又快又稳。