中断后不能直接go mod tidy，需先确认go.mod状态、补全版本后缀、清理缓存、用go get显式拉取；私有库认证失败应配.netrc或insteadof；checksum mismatch需清缓存并强制重下。
迁移中断后不能直接 go mod tidy 继续——它不识别中间态，会误删未完成的 replace 或引入冲突版本。
中断时 go.mod 处于半更新状态怎么办
常见现象是执行 go mod tidy 后报错 require github.com/some/lib: version "v2.1.0" invalid: module contains a go.mod file, so major version must be compatible，或 go build 提示某个包路径找不到。
这是因为中断发生在模块路径重写（如 v1 → v2）过程中，go.mod 里残留了旧导入路径但没同步更新依赖声明。
- 先运行
go list -m all | grep some-lib确认当前实际加载的模块版本和路径 - 手动检查
go.mod中对应require行是否带正确后缀（如/v2），若缺失则补全 - 若本地有
replace但目标路径已不存在，先rm -rf $GOPATH/pkg/mod/cache/github.com/some/lib@*清缓存，再删掉该replace行 - 不要直接
go mod tidy，改用go get github.com/some/lib@v2.1.0显式拉取并修正版本
私有模块认证失败导致迁移卡住
错误信息常为 go get: github.com/private/repo@v1.2.3: reading github.com/private/repo/go.mod at revision v1.2.3: 401 Unauthorized，尤其在 CI 或新机器上首次迁移时高频出现。
这不是网络问题，而是 Go 默认不读取 ~/.netrc 或 Git 凭据管理器中的 token，且 git config --global url."https://token@github.com/".insteadOf "https://github.com/" 在 Go 1.21+ 中部分失效。
- 对 GitHub 私有库：在项目根目录建
.netrc，内容为machine github.com login <code>your_tokenpassword x-oauth-basic，再chmod 600 .netrc - 对 GitLab / 自建 Gitea：确保
git config --global url."https://<code>token@gitlab.example.com/".insteadOf "https://gitlab.example.com/" 已生效，且 token 有read_api权限 - 临时绕过校验（仅调试）：
export GOPRIVATE=github.com/private/*+go env -w GOPROXY=direct，但上线前必须恢复
go.sum 校验失败但文件未变
现象是 go build 报 verifying github.com/xxx@v1.2.3: checksum mismatch，而你确认没动过代码、也没改过 go.sum。
本质是 Go 缓存了旧 checksum，或代理（如 goproxy.cn）返回了被篡改的模块 zip —— 尤其在跨地区网络波动后容易发生。
- 先运行
go clean -modcache清掉本地模块缓存 - 再执行
go mod download -dirty强制重新下载并生成新 checksum - 若仍失败，临时切到官方代理验证：
go env -w GOPROXY=https://proxy.golang.org,direct，成功后再切回原代理 - 严禁手动编辑
go.sum—— 它不是配置文件，是校验快照
最易被忽略的是：迁移中断后，vendor/ 目录可能残留旧模块的符号链接或不完整文件，导致 go build -mod=vendor 成功但运行时 panic。每次中断后，应无条件 rm -rf vendor && go mod vendor 重建。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
