Dockerfile系列(二) 镜像分层与缓存-为什么你的构建这么慢

镜像分层与缓存：为什么你的构建这么慢？

本文基于 Docker 24.x，理解分层机制是写出高效 Dockerfile 的关键。

场景引入：改一行代码，构建五分钟？

上篇咱们写了个能跑的 Dockerfile，但用着用着发现问题了：

我就改了个res.send()里的字符串，重新构建时居然又从头npm install了一遍？！

看着终端里慢悠悠下载依赖的进度条，我开始怀疑人生…

其实啊，这不是 Docker 慢，是你没搞懂它的分层缓存机制。今天咱们就把这个"汉堡分层"原理扒清楚。

核心原理：UnionFS 与镜像分层

镜像到底是什么结构？

Docker 镜像不是一个大文件，而是像汉堡一样一层一层叠起来的：

最上层（可读可写）：你的应用代码 ↓ 中间层：npm install 安装的依赖 ↓ 中间层：package.json 拷贝 ↓ 最底层（基础镜像）：node:18-alpine 操作系统

每一层都是只读的，容器运行时在最上面加一层可写层。这种设计叫UnionFS（联合文件系统）。

类比：汉堡店的预制菜

想象你去快餐店买汉堡：

• 基础镜像（面包底）：工厂批量做好的，大家一样
• RUN 安装依赖（肉饼）：厨房提前煎好的，换的人不多
• COPY 代码（生菜番茄）：每次可能不一样
• 容器运行（你加的黄芥末）：最上面这层，每人自定义

关键是：如果某一层没变，就直接从冰箱里拿预制好的，不用重做。

这就是缓存的本质。

缓存规则：什么时候命中，什么时候失效？

Docker 构建时，从上往下逐层检查：

1. 某一层的内容没变→ 直接用缓存，跳过执行
2. 某一层变了→ 这一层及之后的所有层，全部重新构建

致命陷阱：COPY . .的位置

看个反例：

FROM node:18-alpine WORKDIR /app # ❌ 错误：先把所有代码拷进去 COPY . . # 完蛋：只要改任何代码，这一层就变了 RUN npm install # 缓存失效，重新安装！ EXPOSE 3000 CMD ["npm", "start"]

因为COPY . .把package.json、app.js、README.md全拷进去了，你改个注释，这一层就变了，后面的npm install必须重做。

正确姿势：让不常变的先拷贝

FROM node:18-alpine WORKDIR /app # ✅ 正确：先单独拷 package.json（不常变） COPY package*.json ./ RUN npm install # 依赖没变？直接命中缓存！ # 经常变的代码放后面 COPY . . EXPOSE 3000 CMD ["npm", "start"]

这样只有package.json或package-lock.json变了，才重新npm install。改业务代码？缓存稳稳命中。

实战验证：用docker history看分层

构建完成后，看看镜像的分层结构：

dockerhistorymy-first-app

输出大概长这样：

IMAGE CREATED CREATED BY SIZE abc123 2 min ago CMD ["npm" "start"] 0B <missing> 2 min ago EXPOSE map[3000/tcp:{}] 0B <missing> 2 min ago COPY . . # buildkit 12.3kB <missing> 2 min ago RUN /bin/sh -c npm install # buildkit 45.6MB <missing> 2 min ago COPY package*.json ./ # buildkit 2.1kB <missing> 2 min ago WORKDIR /app 0B <missing> 2 min ago /bin/sh -c #(nop) CMD ["node"] 0B

每一行就是一层，SIZE 表示这层新增的数据量。看到没？npm install那层占了 45MB，这就是我们要极力避免重复执行的原因。

进阶技巧：强制不用缓存

有时候你想彻底重新构建（比如基础镜像更新了）：

# 加 --no-cache，从头来dockerbuild --no-cache-tmy-app.

或者只让某一层失效：在 Dockerfile 里加个小技巧——

# 通过 ARG 传入时间戳，让这层总是变 ARG CACHEBUST=1 RUN npm install

构建时换一下参数，缓存就失效了：

dockerbuild --build-argCACHEBUST=$(date+%s)-tmy-app.

更多缓存优化技巧

1. 合并 RUN 指令，减少层数

每条RUN创建一层。如果多个命令有依赖关系，可以合并：

# 之前：3 层 RUN apt-get update RUN apt-get install -y curl RUN apt-get install -y vim # 优化：1 层，顺便清理缓存 RUN apt-get update && \ apt-get install -y curl vim && \ rm -rf /var/lib/apt/lists/*

最后那个清理很重要！不然apt的缓存会永久留在镜像里占空间。

2. 利用 BuildKit 的缓存挂载

Docker 新版支持更高级的缓存（需要启用 BuildKit）：

# syntax=docker/dockerfile:1 FROM node:18-alpine WORKDIR /app COPY package*.json ./ # 把 npm 缓存挂在主机上，跨构建复用 RUN --mount=type=cache,target=/root/.npm \ npm install COPY . . CMD ["npm", "start"]

这样即使package.json变了，npm 的下载缓存还在，不用重新从网络拉。

一句话总结

Dockerfile 的缓存像叠汉堡：一层变了，上面全重做。把不常变的指令（依赖安装）放前面，常变的（业务代码）放后面，构建速度能快几倍。