答案是运行go mod tidy或go mod download补全校验和。go build -mod=readonly报“missing go.sum entry”本质是go.sum缺失依赖哈希记录，需用工具链自动生成可信元数据，而非手动编辑；indirect模块属正常传递依赖，仅未被直接import；CI报错多因缓存旧go.sum或未同步go.mod变更。
Go 模块依赖的元数据问题，本质是 go.mod 和 go.sum 不一致或缺失导致构建失败、校验报错、版本解析异常。修复不是“重写”，而是让工具链重新生成可信、完整、可复现的元数据。
go build -mod=readonly 报 “missing go.sum entry” 怎么办
这不是网络问题，是 go.sum 缺失某条依赖的哈希记录，Go 拒绝加载未签名模块。
- 先确认是否刚执行过
go get但没提交go.sum：直接git add go.sum - 如果报错的是
indirect模块（比如golang.org/x/net v0.25.0 // indirect），运行go mod download补全校验和 - 不要手动编辑
go.sum—— 它由 Go 工具链自动生成，手改会导致后续go build拒绝加载 - CI 环境出这个错，大概率是缓存了旧
go.sum或没拉取最新go.mod变更
go mod tidy 后 go.mod 里一堆 // indirect，怎么清理
// indirect 是正常现象，表示该模块未被你的代码直接 import，但被某个依赖实际引用了。它不是垃圾，不能靠删掉来“精简”。
- 运行
go list -deps -f '{{if not .Standard}}{{.Path}} {{.Version}}{{end}}' ./查看当前包真正递归依赖的模块（不含标准库） - 如果某个
indirect模块版本异常高（比如v1.20.0），说明上游某依赖已升级它，而你没显式约束——这正是隐性升级风险点 - 从未被任何
import触达的indirect条目，才是残留：执行go mod tidy即可清理 - 想锁定子依赖版本？不能靠在自己项目里
require它，必须用replace或exclude
go mod graph 显示冲突路径，但 go list -m all 版本对不上
这是因为 go list -m all 显示的是最终解析结果（经 MVS 算法选择后的版本），而 go mod graph 显示的是原始依赖声明路径。两者不一致，说明存在版本协商过程。
立即学习“go语言免费学习笔记（深入）”；
- 用
go mod graph | grep 'bad/pkg'定位谁引入了目标模块及其声明版本 - 再用
go mod why -m github.com/bad/pkg查它为什么被引入（具体 import 链） - 若需强制统一版本，在主模块
go.mod中显式require目标版本（如github.com/bad/pkg v1.15.0），Go 会按 MVS 原则尝试满足——但不保证成功，尤其当上游强依赖更高版时 - 真正生效的替换方式只有
replace：它优先级永远高于require，且只影响当前模块构建
本地 replace 没生效，或者 CI 构建失败
replace 是最常用也最容易翻车的元数据干预手段。它不传递给下游，也不参与版本协商，只在当前模块内生效。
- 确认语法正确：
replace github.com/user/dep => ./local/dep，路径必须存在且含有效go.mod - CI 失败常见原因是：replace 指向本地路径（
./xxx），而 CI 环境没有该目录；或忘记在发布前移除临时 replace - 用
go list -m all | grep 'user/dep'验证是否被 replace 覆盖（输出路径应为./local/dep） - CI 中建议禁用 replace：可用
go mod edit -dropreplace=github.com/user/dep临时清理，或用不同go.mod文件区分开发/发布分支
元数据修复的关键在于信任工具链而非手动修补。所有操作都应围绕 go mod tidy、go mod download、go mod verify 展开，而不是编辑 go.sum 或硬编码版本号。最容易被忽略的是：replace 的作用域仅限当前模块，且不会改变 go list -m all 中显示的“逻辑版本”，只改变实际加载路径——这点在调试跨模块行为时尤其致命。
