go mod download总卡在proxy.golang.org是因为国内直连该地址被墙，必须显式设置GOPROXY=https://goproxy.cn,direct，其中direct确保私有模块直连避免认证失败，且应避免用export写入shell配置以防CI环境失效。
go mod download 为什么总卡在 proxy 上
国内用户不配 GOPROXY，go mod download 极大概率超时或卡死——不是网络问题，是默认直连 proxy.golang.org 被墙。它不会报错，就停在那儿不动，像挂了。
- 必须显式设置：
GOPROXY=https://goproxy.cn,direct -
direct是关键：遇到私有模块（比如git.internal.company.com/repo）时跳过 proxy，直接 clone，避免认证失败 - 别用
export GOPROXY=...写进 shell 配置——CI 环境可能没继承，每次命令前加更可靠：GOPROXY=https://goproxy.cn,direct go mod download
本地测试依赖下载，怎么避免改坏全局环境
用 GO111MODULE=on 强制启用 modules，但别让这个变量污染当前 shell。很多人 export 一次，后面所有 go 命令都带上，结果 CI 跑出奇奇怪怪的错误。
- 每个命令单独加前缀：
GO111MODULE=on GOPROXY=https://goproxy.cn,direct go mod download - 不要
cd到 $GOPATH/src 下执行——Go 会降级到 GOPATH mode，go.mod可能被忽略，go test直接报no required module provides package - 测试目录必须是干净的项目根：没有父级
go.mod，不是$HOME/go子目录，pwd输出路径里不能含src
go mod tidy 后发现多了个陌生包，怎么查它从哪来
go mod tidy 补全依赖时，有时会拉进一个你完全没 import 的模块，比如 github.com/you/legacy-util@v0.1.0。这不是 bug，是间接依赖被某个已有包悄悄带进来的。
- 用
go mod graph | grep legacy-util查谁引入了它 - 用
go list -m all | grep legacy-util看是否标记为// indirect - 如果它是 test-only 依赖（只在
*_test.go里 import），govulncheck默认不扫，但go mod download仍会下——得人工确认是否可信 - 删掉它？不行。除非你确定没人 import 它，否则
go mod tidy下次又会加回来
CI 里 go mod download 成功，本地却失败，差在哪
常见现象：GitHub Actions 里一行 go mod download 秒过，你本地跑却 timeout 或 checksum mismatch。根本原因不是网络，是本地 go.sum 和远程校验源不一致。
立即学习“go语言免费学习笔记（深入）”；
- CI 必须加
GOSUMDB=sum.golang.org，强制走官方校验；本地开发可临时关掉（GOSUMDB=off），但切记别提交 -
go mod verify是唯一能暴露问题的命令：它比对本地go.sum和sum.golang.org日志，不一致就失败 - 如果本地
go.sum里有私有模块哈希，而 CI 没权限访问对应仓库，go mod verify会失败——这时要确保私有模块已推送到可用 proxy，或在 CI 中配置 SSH key
go mod download 不检查 go.sum 完整性，只管下包。它成功不代表依赖干净，go mod verify 才是最后一道防线。 
