容器内 go mod download 变慢主因是缓存未复用及 goproxy 配置缺失：dockerfile 中未优先 copy go.mod/go.sum 并立即 run go mod download，导致分层缓存失效；且未通过 env 显式设置 goproxy（如 https://goproxy.cn,direct），致使容器内 fallback 至直连 proxy.golang.org 超时。
容器里 go mod download 变慢，不是因为镜像没优化，而是构建时根本没复用本地缓存，且代理配置常被忽略或失效——GOPROXY 没传进容器、go.mod 复制顺序错、甚至 Dockerfile 里漏了 go mod download 这一步。
为什么容器里依赖下载比本地还慢
本地跑 go mod download 快，是因为模块已缓存在 $GOPATH/pkg/mod；容器是干净环境，每次从零拉取。但真正卡住的点往往不是“没缓存”，而是：
-
GOPROXY环境变量没写进Dockerfile，容器内 fallback 到默认https://proxy.golang.org，直连超时 -
go.mod和go.sum在COPY . .之后才执行go mod download，导致 Docker 缓存失效（只要代码变，前面所有层都重做） - CI/CD 环境未预热缓存，也未挂载
$GOMODCACHE目录，每次构建都重复下载 - 用了
vendor目录却没清理或更新，go build跳过代理直接尝试git clone，触发 DNS 污染或 SSH 认证失败
必须在 COPY go.mod 之后立即 run go mod download
这是 Docker 分层缓存生效的关键。只要 go.mod 不变，go mod download 这一层就永久复用，后续代码变更不影响依赖下载。
正确写法（多阶段示例）：
FROM golang:1.21 AS builder WORKDIR /app # 先复制依赖声明文件，利用缓存 COPY go.mod go.sum ./ # 立即下载，缓存这一步 RUN go mod download # 再复制源码，此时代码变更不影响上面两行 COPY . . RUN go build -o main ./cmd/api
错误写法：COPY . . 放在最前，哪怕只改一行 main.go，go mod download 也会重跑。
容器内 GOPROXY 必须显式设置，不能只靠 go env -w
go env -w GOPROXY=... 写的是宿主机用户级配置，对容器进程完全无效。容器启动时，GOPROXY 是空的，Go 工具链自动 fallback 到 https://proxy.golang.org。
解决方案只有两种：
- 在
Dockerfile中加ENV GOPROXY=https://goproxy.cn,direct（推荐，明确、可审计） - 或在
RUN命令前临时设：RUN GOPROXY=https://goproxy.cn,direct go mod download
注意：,direct 不能省——否则私有模块（如 git.internal.company.com/lib）会因走代理失败；若项目含私有模块，还需配套 ENV GOPRIVATE=git.internal.company.com。
CI/CD 中避免重复下载的实操要点
流水线不是单次构建，要让缓存跨构建复用：
- 在 CI 配置中挂载或缓存
$GOMODCACHE目录（路径通常是/root/go/pkg/mod或$HOME/go/pkg/mod） - 用
go mod download -x加日志，确认请求地址是否为goproxy.cn，而不是proxy.golang.org - 禁止在
Dockerfile中用go get动态拉包——它绕过go.mod声明，无法被缓存，且易触发校验失败 - 如果用了自建 Nexus/Artifactory，把它的地址放
GOPROXY最前：ENV GOPROXY=http://nexus.example.com/repository/goproxy/,https://goproxy.cn,direct
真正容易被忽略的，是 GOPROXY 在容器内必须靠 ENV 或命令行显式传入——没有“继承宿主机配置”这回事；而 go.mod 和 go.sum 的复制时机，决定了整个构建流程能不能稳稳吃上 Docker 缓存。这两点漏掉，再快的镜像也白搭。
