合理拆分 Docker 镜像层应让变化少的部分靠前、变化多的靠后以最大化缓存复用；基础镜像、系统依赖、语言运行时需尽早固定并避免 latest 标签；易变代码和配置应晚出现且单独成层；.dockerignore 过滤无关文件；合并 RUN 指令减少层数并清理缓存；多阶段构建分离编译与运行时，提升构建速度与镜像精简度。
合理拆分 docker 镜像层，本质是让变化少的部分尽量靠前、变化多的部分尽量靠后，这样构建时才能复用更多已有层。缓存不是“越多越好”，而是“越稳越有用”——只要某一层内容没变，docker 就直接跳过执行，连带它之后所有未变的层也一并复用。
把基础环境和依赖放在最上面
基础镜像（如 FROM alpine:3.18）和系统级依赖（如 RUN apk add --no-cache python3）应该尽早出现。这些内容更新频率低，一旦固定下来，后续构建几乎总能命中缓存。
- 固定基础镜像标签，避免用 latest ——否则上游一更新，第一层就失效，整条链全崩
- 把语言运行时、工具链、公共库打包进早期层，比如先 COPY go.mod . && RUN go mod download，再复制源码
- 不建议在依赖安装后立刻 COPY . .，否则代码一改，前面所有层都白缓存了
分离易变内容，减少层污染
应用代码、配置文件、构建产物这些高频变更项，要单独成层，并且尽量晚出现。Docker 只校验 COPY 和 ADD 涉及的文件哈希，所以控制好“哪些文件进来了”，比控制“怎么进”更重要。
- 用 .dockerignore 过滤掉 node_modules、__pycache__、日志、本地配置等无关内容，防止它们意外触发层重建
- 不要把 COPY . . 放太早；可拆成两步：COPY package.json . → 安装依赖 → COPY src/ . → 构建
- 对前端项目，优先 COPY public/ 和 COPY package.json，再 RUN npm ci，最后 COPY . .
合并 RUN 指令，压缩中间层数量
每条 RUN 都生成一层，但很多命令逻辑上是一体的（比如更新源 + 安装包 + 清理缓存）。拆成多条不仅增加层数，还可能因某一步失败导致中间层残留，影响缓存一致性。
- 把相关操作写在同一行，用 && 连接，末尾加 && rm -rf /var/cache/apk/* 等清理动作
- 避免 RUN apt-get update && apt-get install -y curl 和下一行 RUN apt-get clean 分开——第二行会新建一层，但第一层已含下载包，浪费空间又难缓存
- Alpine 下推荐 apk add --no-cache，省去显式清理步骤
用多阶段构建隔离编译与运行时
编译环境（Go、Java、Node）通常体积大、依赖杂，而运行时只需要二进制或精简依赖。多阶段不是为了“分层”，而是为了“换层基底”——让最终镜像只保留真正需要的层，同时让 builder 阶段的缓存独立稳定。
- builder 阶段专注依赖下载和编译，COPY go.mod 和 go mod download 单独成层，代码改了也不影响这层缓存
- runner 阶段用 alpine 或 distroless，只 COPY --from=builder 二进制，不带任何构建工具
- 两个阶段各自缓存互不干扰，构建速度和镜像体积都能兼顾
