背景

只改一行业务代码却重新下载所有依赖，会让构建越来越慢。镜像层顺序应该围绕文件的变化频率安排。

核心判断

  1. 先复制依赖声明并下载依赖，再复制频繁变化的源码。
  2. 设置 WORKDIR，使用多阶段构建将工具链留在构建阶段。
  3. 观察缓存命中率，并定期验证没有缓存时也能构建。

最小示例

下面保留核心逻辑；业务类型、调用入口和环境配置按项目补齐。

COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN go build -o /out/app ./cmd/app

边界与误区

片段是 Go 构建阶段的一部分；go.mod/go.sum 变化仍会失效依赖层。缓存只是加速手段，不能承担产物正确性的证明。

验证方式

分别只改源码、依赖和构建参数，比较构建日志与耗时；最后禁用缓存再构建一次，确认产物和测试结果一致。

小结

先复制依赖描述并安装，再复制源码，让缓存真正服务于日常开发和 CI。