go mod download将缓存写入builder镜像，因默认下载至$GOPATH/pkg/mod（如/go/pkg/mod），若未清理则随Docker层打包进镜像，导致体积膨胀、污染构建；须在go build后立即执行go clean -modcache并清除所有可能路径（如/go/pkg、/root/go/pkg），且合并为单条RUN命令以避免冗余层。
为什么go mod download会把缓存塞进builder镜像
默认执行 go mod download 时，Go 会把模块下载到 $GOPATH/pkg/mod，这个路径在 builder 阶段的镜像里是真实存在的。如果没做清理，Docker 层会把它一起打包进去——哪怕你只用它编译，不运行。
更糟的是，golang:alpine 或 golang:1.22 这类镜像自带完整 GOPATH 和缓存目录，go mod download 后不显式清理，就会让 builder 镜像多出几十 MB 无用数据，还可能污染后续构建。
如何在builder阶段彻底清掉mod缓存
关键不是“少下点”，而是“下了就扔”。必须在 go build 完成后、镜像层固化前，删掉所有缓存路径。
- 用
RUN go clean -modcache && rm -rf /go/pkg /root/go/pkg—— 不只清$GOPATH/pkg/mod，还要清/go/pkg（Docker 默认 GOPATH）和/root/go/pkg（某些 alpine 镜像实际路径） - 避免分步写：不要
RUN go mod download+RUN go build+RUN go clean，这会额外多一层；合并成一条命令：RUN go mod download && go build -o main . && go clean -modcache - 如果用了
BUILDKIT=1，加--mount=type=cache,target=/go/pkg/mod可以让缓存不落盘，但前提是你的 CI 环境支持 BuildKit 且配置了持久化 cache 目录
scratch或distroless镜像里根本不需要mod缓存
runtime 阶段用 scratch 或 gcr.io/distroless/static-debian12 时，连 /bin/sh 都没有，go mod 命令根本不存在。任何残留的 pkg/mod 内容不仅没用，还会让镜像变大、扫描报高危（比如含未签名的第三方模块 ZIP）。
立即学习“go语言免费学习笔记（深入）”；
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
常见错误是 COPY 整个 /app 目录过去，结果把 /app/go/pkg/mod 也带上了。正确做法是只 COPY 二进制：
-
COPY --from=builder /app/main /main—— 显式指定文件路径，不带目录树 - 如果源码里有
embed.FS或需要读取go.mod的逻辑（比如版本打印），才单独 COPY 那个文件，而不是整个go.*目录
CGO_ENABLED=0之后mod缓存其实已失效
一旦设了 CGO_ENABLED=0，Go 就不再拉 C 依赖（如 libgit2、sqlite3），所有纯 Go 模块都静态链接进二进制。此时 go mod download 下的只是编译期临时材料，运行时完全不访问 pkg/mod。
所以只要二进制能跑通 HTTPS、解析 JSON、连接 DB，就说明依赖已全量嵌入，缓存可以安全丢弃。验证方法很简单：
- 在 scratch 镜像里
strace ./main 2>&1 | grep 'open.*mod'—— 应该无任何输出 - 用
go tool objdump -s "main\.init" ./main | grep mod—— 不该出现模块路径字符串
真正容易被忽略的，是那些没加 CGO_ENABLED=0 却又用了 distroless 镜像的构建——这时二进制会试图动态加载 libc，直接 panic，而你还在找 mod 缓存哪去了。
