多阶段构建应以角色或目的命名而非技术动作，如build、runtime-base、service、frontend-build、test、docs-gen，确保名称体现职责、输入、行为与输出，形成清晰接口契约。

多阶段构建的命名，核心是让每个阶段“自己说话”——不用看 dockerfile 内容，仅凭阶段名就能判断它干什么、为什么存在、产出什么。

用角色或目的命名，而不是用技术动作命名
别写 stage1、builder、final 这类模糊词。它们不表达意图，只暴露结构。应聚焦“这个阶段在交付流水线中扮演什么角色”。

按职责清晰分层命名

• 构建阶段 → build（不是 compile 或 build-env）
  明确表示这是源码编译/依赖安装/资产打包环节，例如：FROM golang:1.23 AS build

• 运行时基础环境 → runtime-base（不是 alpine 或 minimal）
  强调它是后续镜像共用的轻量、安全、标准化运行底座，例如：FROM debian:bookworm-slim AS runtime-base

• 最终服务镜像 → service（不是 prod 或 app）
  表明这是对外提供服务的终态镜像，包含最小必要二进制和配置，例如：FROM runtime-base AS service

复杂项目可进一步细化语义

• 前端静态资源构建 → frontend-build
  区别于后端 build，避免歧义；适合含 React/Vue 的全栈项目

• 测试执行环境 → test
  显式声明该阶段专用于运行单元/集成测试，方便 CI 跳过或单独触发

• 文档生成器 → docs-gen
  比如用 Sphinx 或 Docusaurus 构建站点，名字直接说明产出物类型

命名要与上下文一致，避免自造缩写

• 用 migrations，不用 mig；
• 用 lint，不用 linter-stage；
• 若项目有统一前缀（如团队约定所有阶段加 ci-），则保持： ci-build、ci-test —— 但前提是整个团队已共识且文档化。

本质上，Dockerfile 的每个 AS xxx 都是一份微型接口契约。名字就是契约标题：它承诺了输入、行为和输出。名字准了，别人一眼就懂要不要复制、修改或依赖它。