go mod download 在最小化系统中失败，主因是缺 git、ca 证书、curl 等基础依赖，导致 https 请求失败、git clone 报错或 tls 校验不通过；需先安装 git ca-certificates gcc 等包，并设 goproxy=https://goproxy.cn,direct 后执行 go mod download all。
最小化安装的系统（比如 Alpine、CentOS minimal、Ubuntu Server minimal）通常缺编译工具链、Git、CA 证书甚至 curl，直接跑 go mod download 很容易卡在“找不到 git”“x509: certificate signed by unknown authority”或“exec: 'git': executable file not found in $PATH”上。这不是 Go 的问题，而是环境没配齐——得先补依赖，再下模块。
为什么 go mod download 在最小化系统里会失败
Go 默认用 git 克隆私有模块、解析 https:// 协议的模块源、校验 TLS 证书；同时依赖系统 CA 证书库验证 HTTPS 连接。最小化系统往往：
- 没装
git（go mod download对非 proxy 模块会 fallback 到 git clone） - 没装 CA 证书包（如
ca-certificates），导致 HTTPS 请求失败 - 没装
gcc或musl-dev（虽不直接影响download，但后续go build可能报错，提前装更省事） -
GOPROXY设成direct或未设时，Go 会直连模块源站，对网络和工具链要求更高
必须安装的基础系统依赖
不同发行版命令略有差异，但核心包名一致。执行前确认你有 root 权限：
Alpine Linux：
apk add --no-cache git ca-certificates gcc musl-dev
CentOS/RHEL minimal：
yum install -y git ca-certificates gcc make
Ubuntu/Debian minimal：
apt update && apt install -y git ca-certificates gcc
装完立刻验证：
-
git --version能输出版本号 -
curl -I https://goproxy.cn不报SSL certificate problem -
go env GOPROXY确保不是空值；若为空，建议设为：go env -w GOPROXY=https://goproxy.cn,direct
go mod download all 是唯一可靠选择
最小化环境资源紧张，不能靠多次 go build 触发“按需下载”。必须一次性拉全所有模块，否则离线或 CI 中断后很难定位漏了哪个 indirect 依赖。
运行前确保：
-
go mod tidy已执行过，go.mod和go.sum是最新状态 - 没有
replace指向远程 URL（如replace example.com/a => https://github.com/x/a v1.2.0），这种写法会让go mod download all跳过它，等构建时才拉——而那时可能已无网 - 执行：
go mod download all（注意：all是关键字，不是通配符）
它等价于 go list -m all | xargs go mod download，会覆盖整个模块图，包括所有 indirect 依赖。但不会处理 vendor 目录或 replace 到本地路径的模块（它们本就不需要下载）。
离线复制缓存前的最后检查
下载完成后，别急着打包。先验证缓存是否真完整：
- 运行
go mod verify，无输出即校验通过；若有missing hash错误，说明go.sum和缓存不匹配，需重新tidy+download all - 临时关网测试：
export GOPROXY=off GOSUMDB=off，再跑go list -m all—— 如果不报错、输出全量模块列表，说明缓存已就位 - 模块缓存路径默认是
$GOPATH/pkg/mod，确认该目录下有cache/download/和对应域名子目录（如github.com/）
真正容易被忽略的是：即使所有模块都下了，如果项目用了 //go:embed、cgo 或带 build tags 的条件编译，go list -m all 也覆盖不到那些分支里的依赖——它们只在构建时才解析。这类情况必须在目标环境实测 go build -v 才能暴露。
