Docker 镜像分层原理与构建缓存优化实践

为什么镜像越构建越慢

很多团队都会遇到同一个现象：Dockerfile 没怎么改，`docker build` 却越来越慢，最后只能加一句 `--no-cache` 硬扛。其实大多数时候不是 Docker 变慢了，而是构建缓存没有命中。理解镜像分层与缓存规则，能让构建时间从几分钟降到几十秒。

一、每一层都发生了什么

Dockerfile 中的 `RUN`、`COPY`、`ADD` 等指令通常各自产生一个只读层，层与层之间通过联合文件系统叠加。镜像的本质就是一串层的引用，容器启动时在最上层加一个可写层。由此可以推导出两个重要结论：

1. 层是只读且可复用的，相同内容的层可以被多个镜像共享，所以基础镜像拉取后不会重复下载。
2. 一层的缓存失效，它之后的所有层都会失效，因为后续层是基于前一层的结果构建的。

这也是优化构建的核心思路：把变化频率低的内容放在前面，变化频繁的内容放到最后。

二、缓存命中的判定规则

构建时，Docker 会为每条指令计算缓存键。对于 `RUN`，键主要由指令本身和父层决定；对于 `COPY`/`ADD`，键还包含被复制文件的元数据与内容校验和。只要校验和变化，缓存就不命中。

常见踩坑是写了这样一行：

COPY . .
RUN npm install

项目里任意一个文件改动，都会让 `COPY` 层的校验和变化，导致后面 `npm install` 全部重跑。正确的顺序是先复制依赖清单，再安装依赖，最后复制源码：

COPY package.json package-lock.json ./
RUN npm ci --omit=dev
COPY . .

这样只要依赖清单没变，安装依赖这一层的缓存就能稳定命中。

三、几个实用的优化习惯

第一，把 `apt-get update` 和 `apt-get install` 写在同一条 `RUN` 里，并在结尾清理缓存。分开写会产生过期索引，也会多出一层无用的元数据。

第二，使用多阶段构建。编译工具链只保留在 builder 阶段，最终镜像只复制产物，既能减小体积，也能减少攻击面。

第三，用 `.dockerignore` 排除 `node_modules`、`.git`、日志和本地缓存目录。这些文件既会污染构建上下文，也会让 `COPY` 的校验和频繁变化。

第四，为镜像打上明确的基础镜像版本标签，例如 `node:20.11-alpine`，避免 `latest` 漂移导致某天构建结果与预期不一致。

四、怎么验证优化是否有效

不要只看总耗时，可以分两次构建对比：第一次全量构建，第二次只改一个源码文件再构建。观察日志中命中缓存的层数，如果改动源码后只有最后的复制层重建，说明分层顺序是合理的；如果从依赖安装开始全部重建，就要回头检查 `COPY` 的位置。

构建缓存不是玄学，它完全由指令顺序和文件内容决定。把 Dockerfile 当作一份有依赖关系的构建脚本，按变化频率排序，绝大多数慢构建都能被稳定解决。