直接设GOPROXY=https://goproxy.cn,direct并清缓存可解决90%包不完整问题，因Go工具链不会自动删除下载中断的破损.zip或校验残留，导致后续build报missing files、checksum mismatch或静默跳过子模块。
直接设 GOPROXY=https://goproxy.cn,direct 并清除本地缓存，能解决 90% 的“包不完整”现象——这不是 Go 编译器出错，而是模块下载中途断连后残留了损坏的 .zip 或校验信息，后续命令仍复用它，导致 go build 报 missing files、verifying xxx: checksum mismatch 或静默跳过某些子模块。
为什么 go mod tidy 后仍有文件缺失
根本原因是 Go 工具链在下载失败时不会自动删除已写入一半的模块缓存，而是保留破损状态。下次运行 go mod tidy 或 go build 时，它会认为“这个版本已存在”，跳过重拉，但解压或校验阶段才发现 zip 损坏或 go.sum 条目不匹配。
-
go.mod里声明了golang.org/x/net v0.25.0，但$GOPATH/pkg/mod/cache/download/golang.org/x/net/@v/v0.25.0.zip只写入了前 60%，go build解压时报zip: not a valid zip file - 网络抖动发生在 checksum 获取阶段，
go.sum写入了旧哈希值，而缓存里实际是新内容（或反之），触发checksum mismatch - 某些模块（如
gopacket）依赖多层子模块，go mod tidy可能只拉了顶层，子依赖因超时被跳过，go build到 import 时才报no required module provides package
go clean -modcache 必须配合 go mod download 使用
只清缓存不重拉，等于清空仓库却不补货；只拉不清，等于往坏库里硬塞新货。二者必须成对执行：
- 先运行
go clean -modcache—— 彻底删掉$GOPATH/pkg/mod下所有模块和缓存索引 - 再立即运行
go mod download（非tidy）—— 它强制按go.mod列表逐个下载，不跳过、不推导，失败即停，便于定位具体哪个模块卡住 - 若某模块反复失败（如
github.com/xxx/yyy），可单独拉：go mod download github.com/xxx/yyy@v1.2.3，避免全量重试
内网或弱网环境要关 GOSUMDB，不能只调 GOPROXY
很多人设了 GOPROXY=https://goproxy.cn,direct 就以为万事大吉，结果 go build 卡在 fetching sum.golang.org。这是因为 GOSUMDB 默认仍连境外校验服务，与代理无关。
立即学习“go语言免费学习笔记（深入）”；
- 测试/离线环境：执行
go env -w GOSUMDB=off，彻底跳过校验（仅限可信构建链） - 生产内网：若已部署内网
sum服务（如https://goproxy.internal/sum），则设go env -w GOSUMDB=https://goproxy.internal/sum - 绝对不要设
GOINSECURE=*—— 它会让所有模块（包括私有 Git 域名）跳过校验，CI 流程中极易引入恶意包
最容易被忽略的是 direct 的位置和 GOSUMDB 的联动：漏掉 direct 会导致私有域名被转发到代理并 404；漏关 GOSUMDB 会导致代理拉成功了，校验阶段仍失败。这两个变量必须同时检查、同时生效。
