go mod graph 可一眼揪出循环依赖回边或孤立节点，运行 go mod graph | grep -e 'pkga|pkgb' 若出现 pkga → pkgb → pkga 即为循环源；若某包只出不进则可能是冗余或路径错误。
go mod graph 一眼揪出损坏依赖的回边
模块依赖损坏常表现为 go build 报 import cycle not allowed 或 cannot find module，但错误不指明具体路径。直接看 go mod graph 输出最有效——它把所有 require 关系扁平展开成有向边，损坏包通常出现在循环边或孤立节点里。
- 运行
go mod graph | grep -E 'broken|utils|model'，快速过滤可疑包名（把broken换成你怀疑的包） - 若输出含
pkgA -> pkgB -> pkgA这类闭环，就是循环依赖源；若某包只出不进（如pkgX ->末尾无箭头），说明它被 require 但没被任何包 import，大概率是冗余或路径错 - 注意：
go mod graph不包含测试文件和//go:embed引入的隐式依赖，真要排查得加go list -f '{{.ImportPath}} -> {{join .Imports " -> "}}' ./...
go list -m all 显示实际加载的模块版本
go list -m all 展示当前构建实际解析出的模块列表及版本，比 go.mod 更真实——它反映 Go 工具链最终选中的版本，能暴露 replace 覆盖、indirect 冲突或私有模块解析失败等问题。
- 执行
go list -m all | grep 'github.com/yourorg/broken'，确认该模块是否出现在结果中；若没出现，说明它根本没被解析到，可能是路径拼错、go.mod缺失或GO_PRIVATE未配置 - 若出现但版本号异常（如
v0.0.0-00010101000000-000000000000），代表 Go 无法从源拉取，只能 fallback 到伪版本，此时需检查网络、代理或私有仓库权限 - 对比
go list -m all和cat go.mod | grep require，若某行require在前者中消失，说明该依赖未被任何代码 import，go mod tidy下次会删掉它
go mod verify 验证 go.sum 是否被篡改
go mod verify 检查本地 go.sum 中记录的校验和是否与实际下载的模块内容匹配。依赖损坏有时不是代码问题，而是 go.sum 被手动编辑、CI 缓存污染或代理中间篡改导致校验失败。
- 运行
go mod verify，若报mismatch for module，立刻停手——不要go mod tidy覆盖，先用go mod download -json github.com/xxx/yyy@v1.2.3看实际下载的校验和，再对比go.sum里对应行 - 常见坑：团队中有人关了
GOSUMDB=off后 commit 了脏go.sum，其他人拉下来就 verify 失败；修复方式是go clean -modcache清缓存，再go mod download重拉 -
go mod verify不检查 replace 指向的本地路径，那些包跳过校验——所以本地调试时务必记得上线前删掉replace行
go build -x 查看编译时实际加载的源码路径
当怀疑某个依赖包被“假加载”（比如缓存旧版 .a 文件或 GOPATH 干扰），go build -x 能打印每一步调用的命令和文件路径，清楚看到 Go 到底用了哪份源码。
- 执行
go build -x ./...（注意是./...不是main.go），在输出里搜索compile或pack，找类似/home/user/go/pkg/mod/github.com/xxx/yyy@v1.2.3/zzz.go的路径 - 若路径指向
pkg/mod下的模块，说明走 Modules 正常流程；若指向GOPATH/src或./local/xxx，就得检查是不是replace或环境变量搞混了 - 特别注意：如果输出里出现
asm或cgo相关命令但失败，往往不是依赖损坏，而是 C 工具链缺失——别往模块上瞎查
go.mod 里写错的模块路径（比如少个 v2 后缀）、replace 指向的本地目录里没有 go.mod、或者 go.sum 被 IDE 自动格式化工具误删了换行——这些细节不会报明显错误，但会让依赖链在某一层无声断裂。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
