要查看 go mod download 的完整网络请求和校验过程，需设置 goproxy=direct、godebug=modcacheverify=1 和 golog=moddownload（go 1.21+），或降级用 godebug=modfetchhttp=1；校验失败时日志会显示具体 hash 不匹配，且默认仅警告不中断，需 -x 或 gosumdb=off 才强制报错。
go mod download 时如何看到完整网络请求和校验过程
默认情况下 go mod download 只输出简略进度，看不到模块从哪下载、是否走 proxy、校验失败的具体原因。要展开这些细节，必须启用 Go 的调试日志开关。
关键不是加 -v（它只显示模块名），而是设置环境变量：GOPROXY=direct + GODEBUG=modcacheverify=1 + GOLOG=moddownload。其中 GOLOG=moddownload 是 Go 1.21+ 才支持的开关，会打印每一步的 fetch、checksum 验证、写入缓存路径等动作。
- 如果用的是 Go 1.20 或更早版本，
GOLOG不生效，只能靠GODEBUG=modfetchhttp=1查看 HTTP 请求头和响应状态 -
GOPROXY=direct能绕过代理直连源站，避免 proxy 层掩盖真实校验失败点（比如 checksum mismatch 实际发生在 proxy 缓存层） - 校验失败时，日志里会出现类似
verifying github.com/sirupsen/logrus@v1.9.0: checksum mismatch，接着会列出本地缓存的 hash 和预期 hash 值
为什么 go.sum 文件校验失败却没报错？
Go 默认在 go build 或 go run 时才强制校验 go.sum，而 go mod download 即使发现 mismatch 也只警告不中断——除非你加了 -x 参数或设置了 GOSUMDB=off。
真正触发硬校验的场景是：模块首次下载后写入 go.sum，后续每次构建都会比对缓存中模块 zip 的实际 hash 和 go.sum 记录值。若不一致，报错信息是：verifying github.com/xxx@v1.2.3: checksum mismatch。
- 常见诱因是手动修改过
go.sum，或用了不兼容的 GOPROXY（如某些私有 proxy 返回了篡改过的 zip） - 临时跳过校验可用
GOSUMDB=off，但生产环境严禁使用 - 修复方式不是删
go.sum，而是运行go mod download -dirty（Go 1.22+）或go clean -modcache && go mod tidy
如何定位某个模块究竟从哪个 URL 下载
Go 不会直接打印下载地址，但可通过组合调试开关暴露出来：GODEBUG=modfetchhttp=1 GOLOG=moddownload go mod download github.com/gorilla/mux@v1.8.0。
输出里会有类似这样的行：modfetch: fetching https://api.github.com/repos/gorilla/mux/zipball/v1.8.0（直连）或 https://proxy.golang.org/github.com/gorilla/mux/@v/v1.8.0.info（走 proxy）。注意 info 请求只是查元数据，真正 zip 下载地址藏在后续的 .zip 请求里。
- 如果用的是私有 proxy（如 Athens），确保其配置允许返回原始 URL，否则日志里只会显示 proxy 自己的路径
- 某些企业网络拦截 HTTPS 重定向，会导致
GET https://sum.golang.org/...失败，此时需配GOSUMDB=sum.golang.org+https://sum.golang.org显式指定校验服务地址 - 模块带 replace 时，日志里出现的 URL 是 replace 后的目标路径，不是原始 module path
go mod verify 报错但日志没线索怎么办
go mod verify 本身不输出详细过程，它只检查当前 go.sum 和磁盘上模块内容是否一致。出错时只告诉你哪个模块 mismatch，不讲在哪一步断的。
真正有用的组合是：go mod download -x + go mod verify -v。前者展开所有下载命令（含 curl/wget 调用），后者在 verify 时打印每个模块的 hash 计算结果。
-
-x会显示类似# get https://proxy.golang.org/github.com/gorilla/mux/@v/v1.8.0.zip的底层命令，可复制出来手动 curl 看响应体 -
go mod verify -v输出形如github.com/gorilla/mux v1.8.0 h1:... (expected) != h1:... (actual)，对比这两个 hash 能快速判断是本地文件损坏还是 sum 记录错误 - 如果模块用了
replace指向本地路径，verify 不会校验本地目录内容，此时需手动sha256sum对比
最常被忽略的是：Go 的校验基于模块 zip 包解压后的文件树 hash，不是 zip 文件本身的 hash。所以哪怕 zip 下载完整，解压时权限或换行符差异也会导致 mismatch。
