Docker多阶段构建Next.js为何采用三阶段而非两阶段？

你观察得很准——最终的运行镜像看起来确实没什么差别，但三阶段构建的优势主要体现在构建过程的效率和可维护性上，而非最终镜像的大小。咱们来拆解一下：

核心优势1：最大化利用Docker分层缓存，大幅加快构建速度 #

Docker的镜像分层缓存是按步骤复用的：如果某一步的上下文（比如文件内容）没变化，就直接用之前的缓存层。

• 在三阶段构建里，deps阶段只负责安装依赖，只有当package.json或package-lock.json（或yarn.lock）变更时，这个阶段才会重新执行npm install。
• 而builder阶段只负责构建应用，当你修改业务代码（src、public里的内容）时，Docker会直接复用deps阶段缓存好的node_modules，不用重新安装依赖。

如果改成两阶段（把依赖安装和构建合并），每次修改代码都会触发整个阶段重新执行——哪怕依赖根本没变化，也得重新跑一遍npm install，这在依赖较多的项目里会浪费大量时间。

核心优势2：构建阶段职责更清晰，可维护性更强 #

把依赖安装、应用构建、运行环境拆成独立阶段，每个阶段的目标更明确：

• deps阶段：专注处理依赖，不用关心代码结构
• builder阶段：专注编译构建，只需要拿到依赖就能工作
• 运行阶段：只保留运行必需的文件，干净精简

这种拆分让Dockerfile的逻辑更清晰，后续修改（比如换依赖管理工具、调整构建命令）时，只需要改动对应的阶段即可，不会牵一发而动全身。

为什么最终镜像看起来一样？ #

因为最终的运行阶段都是从builder阶段复制.next、public、node_modules和package.json这些运行必需的文件，不管是两阶段还是三阶段，最终复制的内容是一致的，所以镜像大小和内容自然没差别。但构建过程的体验和效率是完全不同的。

举个实际的例子：如果你每天要构建10次镜像，每次修改业务代码，三阶段构建每次能省掉5-10分钟的依赖安装时间，日积月累下来的效率提升非常明显。

内容的提问来源于stack exchange，提问作者Omiron