因为每个run指令都会新增一个只读镜像层，即使后续用rm删除文件，前层中被删内容仍残留，导致层数和体积叠加。
为什么RUN指令越多镜像层数反而越大
Docker 每个 RUN 指令都会固化一层文件系统快照，哪怕你紧接着用 rm -rf /tmp，那个被删掉的文件仍存在于前一层中。比如：RUN go mod download → RUN go build -o app . → RUN rm -rf $GOPATH/pkg，这三步会生成三层，且第三层无法抹去前两层残留的缓存和对象文件。
- go mod download 写入的
/go/pkg/mod/cache默认保留在 builder 镜像里，不显式清理就随层固化 -
COPY . .把.git/、testdata/全带进构建上下文，即使后面RUN rm -rf .git，也只新增一层“删除记录”，体积没减 - Alpine 上用
apk add git再apk del git分两行写，中间状态会被缓存，导致 git 二进制残留在某一层
如何合并RUN并精准清理中间产物
关键不是“少写RUN”，而是让所有依赖安装、编译、清理发生在同一层——这样临时文件根本不会写入最终镜像。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 把
apk add --no-cache和apk del合并在一行：RUN apk add --no-cache git make && go build -o app . && apk del git make - go mod download 后立刻清空缓存：
RUN go mod download && rm -rf /go/pkg/mod/cache - 构建完成后删掉源码和 vendor（如果用了）：
RUN CGO_ENABLED=0 GOOS=linux go build -o /app . && rm -rf /app/*.go /app/vendor /app/go.mod /app/go.sum - 别信
go build -trimpath能替代清理：它只隐藏源码路径，不删/go/pkg或/root/.cache/go-build
COPY --from=builder 时路径写错导致中间层白清
常见错误是以为只要 COPY --from=builder /app/app . 就万事大吉，结果发现最终镜像仍有 /go 或 /root/.cache ——那说明你没在 builder 阶段末尾真正删干净，或者 COPY 的源路径压根没覆盖到那些目录。
- builder 阶段的
WORKDIR是/app，但/go/pkg在根目录，rm -rf /go/pkg必须显式写，不能靠 WORKDIR 隐含 -
COPY --from=builder只复制指定路径下的文件，不会自动排除/etc或/usr/local/go，这些得靠 builder 阶段自己删 - 验证是否清干净：
docker run --rm -it <image> find / -name "go.mod" 2>/dev/null</image>，有输出就说明.dockerignore没生效或 builder 清理漏了
BuildKit 能帮你跳过哪些传统陷阱
启用 BuildKit（DOCKER_BUILDKIT=1 docker build）后，RUN --mount=type=cache 可把 go mod download 缓存独立出来，不污染 builder 镜像层；同时支持更细粒度的缓存复用，避免因注释变动或空行导致整层失效。
- 不用再手动
rm -rf /go/pkg/mod/cache，改用：RUN --mount=type=cache,target=/go/pkg/mod/cache go mod download -
COPY --link（BuildKit 特性）能让多处 COPY 共享同一层，避免重复拷贝相同文件 - 但注意：BuildKit 不自动清理
.git或vendor/，.dockerignore仍必须写全：.git、testdata/、**/*.go~、examples/
/go/pkg，却忘了 /root/.cache/go-build；或者用了 go.work，但没在 builder 中执行 go work use ./，导致模块解析失败而 fallback 到全局 cache ——那部分就根本没被你控制。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
