go mod download卡住或失败主因是GOPROXY未正确配置，应设为https://goproxy.cn,direct并确保GONOPROXY与GONOSUMDB同步排除私有域名，再清理缓存go clean -modcache。
go mod download 卡住或失败，大概率是代理没配对
Go 默认走 https://proxy.golang.org，这个地址在国内直连成功率极低——不是你网络差，是它本身没做国内节点优化，常见现象包括 TLS 握手超时、DNS 解析失败、连接重置。直接切到国内可信镜像就能解决 80% 的问题。
-
go env -w GOPROXY=https://goproxy.cn,direct是最稳妥的配置，direct必须带上，否则私有模块会 404 - 避免用已停服的
https://goproxy.io（返回 502）或无 HTTPS 的 http 地址（Go 拒绝加载） - 多个代理可用竖线
|分隔：go env -w GOPROXY="https://goproxy.cn|https://mirrors.aliyun.com/goproxy|direct"，Go 1.15+ 支持顺序尝试 - 执行后务必验证：
go env GOPROXY输出应与设置一致，再试go mod download看是否跳过proxy.golang.org
私有模块拉不到？GONOPROXY 和 GONOSUMDB 必须同步设
公司内网 Git（如 git.internal.company.com）或 GitHub 私有组织仓库，如果只配 GOPROXY 不排除，Go 会先发请求到代理，必然失败。关键不是“绕过代理”，而是让 Go 明确知道哪些域名该直连 + 跳过校验。
-
go env -w GONOPROXY=git.internal.company.com,github.com/my-org—— 域名必须精确匹配，不支持通配符 -
go env -w GONOSUMDB=git.internal.company.com,github.com/my-org—— 和GONOPROXY值完全一致，否则go get会因 checksum 校验失败拒绝拉取 - 若用
direct作兜底，GONOPROXY仍需显式声明，否则 Go 会误判为可代理路径
checksum mismatch 不是网速问题，是缓存或镜像源不一致
报 verifying github.com/xxx@v1.2.3: checksum mismatch，说明本地缓存或代理返回的模块内容和 sum.golang.org 记录的哈希不一致。常见于镜像同步延迟、自建 proxy 未透传校验和、或本地 $GOPATH/pkg/mod 被污染。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 第一步清缓存：
go clean -modcache，再重试 - 确认你用的镜像源是否透传官方校验：
goproxy.cn和mirrors.aliyun.com/goproxy都支持，但某些老旧自建 proxy 若配了GOINSECURE或跳过校验，就会出问题 - 临时调试可关校验：
go env -w GOSUMDB=off，但上线前必须恢复，否则失去依赖完整性保护
Docker 构建里依赖反复下载？Dockerfile 顺序决定缓存是否生效
在 Docker 中，go mod download 是否被缓存，取决于它在 Dockerfile 中的位置。如果放在 COPY . . 之后，每次代码变更都会使前面所有层失效，依赖重新下载。
立即学习“go语言免费学习笔记（深入）”；
- 把
go mod download放在COPY go.mod go.sum .之后、COPY . .之前 - 确保
.dockerignore排除了node_modules/、vendor/等无关目录，避免COPY触发缓存失效 - 多阶段构建中，构建阶段执行
go mod download，运行阶段不再需要源码和缓存，镜像更小也更干净
GONOPROXY 和 GONOSUMDB 的值必须一字不差地一致，少一个域名、多一个空格都会导致私有模块拉取失败，且错误提示不明确。 
