报 missing go.sum entry 时应先删 go.sum 再执行 go mod tidy，因该错误源于校验文件与模块声明不一致，而非依赖破损；go mod tidy 会自动重建完整校验快照。
go mod tidy 报 missing go.sum entry 怎么办
这不是依赖“破损”，而是本地校验文件与声明不一致，常见于手动改过 go.mod、切换 Git 分支漏掉 go.sum、或 GOPROXY 缓存异常。直接删 go.sum 再跑 go mod tidy 是最稳妥的恢复动作。
- 先确认错误是否真由校验缺失引起：运行
go mod verify，若报missing hash或different checksum，说明go.sum确实失效 - 不要只删某几行——
go.sum是整体快照，局部清理易引发连锁校验失败；直接删整个文件更安全 - 删完后立即执行
go mod tidy，它会重新下载所有依赖并生成新go.sum - 如果
go mod tidy卡住或报unknown revision，大概率是 GOPROXY 不可达或私有模块未配置GOINSECURE/GOPRIVATE，不是go.sum本身的问题
go build 报 cannot find module providing package
本质是 Go 找不到 import 路径对应的模块，不是版本冲突，而是路径解析失败。优先检查模块是否初始化、路径是否合规、replace 是否误写。
- 确认当前目录下存在
go.mod，且go env GO111MODULE输出为on；若为auto或off，立刻执行go env -w GO111MODULE=on - 检查 import 路径是否拼错，比如
github.com/user/repo/sub实际模块路径是github.com/user/repo/v2/sub（含 v2） - 若用了
replace，运行go list -m all | grep 包名看是否真被重定向；常见错误是 replace 路径写成./local但实际目录名是../local-fix - 项目不能放在
$GOPATH/src下——Go 会退化为 GOPATH 模式，忽略go.mod；移到~/projects/myapp这类干净路径再试
依赖回滚后构建失败，怎么验证是否真回滚成功
手动改 go.mod 版本号或用 go get 回滚后，必须验证实际加载的模块是否如预期，否则容易误判。
- 执行
go list -m all | grep 包名，输出应包含你指定的旧版本号（如v1.2.3），且来源路径不带// indirect（表示已被直接采纳） - 运行
go mod graph | grep 包名，看是否所有引用都指向同一版本；若仍有其他版本出现，说明某间接依赖强制拉了更高版，需用require显式锁死 - 删掉
go.sum和go.work（如有），再跑go mod tidy，避免缓存干扰验证结果 - CI 构建失败但本地正常？大概率是 CI 环境没执行
go mod download，导致pkg/mod缓存缺失旧版本——在 CI 脚本里显式加这一步
replace 导致本地能跑、CI 失败，如何快速隔离问题
replace 在本地调试很高效，但极易因路径/权限/网络差异在 CI 失效，排查要从构建上下文入手。
立即学习“go语言免费学习笔记（深入）”；
- CI 中禁止使用
./xxx或../xxx这类相对路径的replace；一律改用 commit hash 或 fork tag，例如replace github.com/org/pkg => github.com/your-fork/pkg v0.0.0-20230510142234-a1b2c3d - 在 CI 脚本开头加
go list -m all，把输出日志保留下来，对比本地结果，一眼看出哪个模块被替换成不同路径 - 临时禁用 replace：执行
go mod edit -dropreplace=github.com/org/pkg，再跑go mod tidy，看是否回归原始冲突——能快速确认问题是否真由 replace 引起 - 上线前必须清理 replace：它不传递给下游，也不解决兼容性，只是临时补丁；长期留着等于把技术债打包进主干
go.mod、本地 pkg/mod 缓存是否存在对应版本、以及 GOPROXY 能否实时解析该版本。缺一不可，任何一环断开，go mod tidy 都只会沉默失败。 
