checksum mismatch 错误本质是模块zip包内容与go.sum记录的哈希值不匹配，主因包括本地缓存损坏、代理返回污染包或作者强制覆盖tag；应先执行go clean -modcache并删除go.sum，再用go mod tidy重建，若仍失败则需验证goproxy或改用commit hash锁定版本。
checksum mismatch 错误不是网络问题，而是模块内容与 go.sum 记录不一致；跳过校验或删 go.sum 不解决问题，只会掩盖风险。
为什么 go get 报 checksum mismatch 不能靠重试解决
这个错误表示 Go 下载的模块 zip 包内容，和 go.sum 文件里存的哈希值对不上。它不是连接超时、404 或权限拒绝——那些会直接报 network error 或 forbidden。checksum mismatch 是校验阶段失败，说明你拿到的文件“看起来能解压”，但字节级内容已变。
- 常见诱因包括：本地模块缓存损坏（
$GOPATH/pkg/mod/cache里某个包被截断或写入异常） - 代理节点返回了旧版/污染版 zip（比如企业内网 proxy 在 zip 流中注入 header）
- 模块作者用
git push --force覆盖了已发布的 tag，导致同一 tag 指向不同 commit
go clean -modcache 是最有效的第一步
别手动删 cache/download 子目录，也别只删某个模块路径——Go 的缓存是分层索引结构，局部清理可能留下脏状态。必须整仓清空：
- 执行
go clean -modcache（注意：它不碰go.mod，也不删你代码） - 顺手删掉项目根目录下的
go.sum（避免旧哈希干扰重建） - 再跑
go mod tidy或go get -u example.com/repo
如果这时成功，说明问题出在缓存；如果仍失败，说明问题在远程源或代理。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
验证 GOPROXY 是否可信：临时切 direct
国内常用 https://goproxy.cn 或 https://proxy.golang.org，但镜像站只做转发，不担保内容一致性。用 direct 可绕过所有中间环节，直连原始源（如 GitHub、GitLab）：
- Linux/macOS：
export GOPROXY=direct - Windows：
set GOPROXY=direct - 再执行
go mod download example.com/repo@v1.2.3
若 direct 成功而原 proxy 失败，说明该 proxy 节点缓存异常或同步滞后。可改用多源兜底配置：GOPROXY=https://goproxy.cn,https://proxy.golang.org,direct。
作者强制覆盖 tag 时，只能用 commit hash 锁定
这是唯一无法自动修复的情况：tag 本身没变，但 zip 包内容变了（v1.2.3 对应两个不同 commit）。Go 的 checksum 是按 zip 算的，内容一变就对不上。
- 先查
go.sum里该模块行，看它记录的是哪个 hash - 运行
go mod download -json example.com/repo@v1.2.3，观察Version字段是否变成 pseudo-version（如v1.2.3-0.20230101000000-a1b2c3d4e5f6） - 确认后，放弃 tag，改用 commit hash：
go get example.com/repo@a1b2c3d
commit hash 不会被覆盖，是唯一可信赖的锚点；但要注意它绕过了语义化版本约束，后续需人工关注兼容性。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
