破损依赖最直观信号是go list -m all输出中出现“(unknown)”，表明Go无法解析模块版本，常见原因包括路径错误、GOPRIVATE未配置、私有模块未发布tag或缺少replace声明；go mod graph中无版本号的边及go mod why报“no required module provides package”也指向路径错误或import残留。
破损依赖通常不是版本号写错，而是 Go 工具链根本找不到那个模块——要么路径不对、要么网络不通、要么权限不够。直接看 go list -m all 和 go mod graph 就能快速定位，不用猜。
go list -m all 输出里出现 “(unknown)” 或空版本
这是最直观的破损信号。只要某行末尾是 (unknown)，说明 Go 无法解析该模块的版本信息，大概率是路径拼错、私有仓库没配 GOPRIVATE，或模块压根没发布 tag。
-
go list -m all | grep '(unknown)'快速筛出问题模块 - 检查该模块是否在
go.mod的require中写了错误路径（比如少了个/v2后缀） - 如果是公司内网 Git 地址，确认已执行
go env -w GOPRIVATE="git.internal.company.com" - 若模块是本地子模块，但没加
replace，go list也会显示(unknown)—— 此时必须补上replace github.com/xxx => ./xxx
go mod graph 里某模块只出现不带版本号的行
像 example.com/app github.com/some/lib 这种没带 @vX.Y.Z 的边，代表 Go 没法确定用哪个版本，往往是因为该模块未被任何 require 显式声明，又没出现在 go.sum 中。
- 运行
go mod graph | grep 'github.com/some/lib$'（注意结尾 $）确认是否真没版本 - 再查
go list -m github.com/some/lib，如果返回module github.com/some/lib: not found，说明它不在当前模块树里，只是 import 路径残留 - 常见于删了 import 但没运行
go mod tidy，此时手动删掉go.mod里残留的require行，再 tidy - 也可能是跨模块引用时子模块没提交
go.mod，导致主模块无法识别其版本
go mod why 显示 “no required module provides package”
这个错误不是说包不存在，而是说当前模块的依赖图里没有任何一个模块声明了对它的 require，但它却被代码 import 了——典型症状是路径写错、拼写错误，或用了未发布的内部路径。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 执行
go mod why -m github.com/bad/path，如果输出全是(main module does not need github.com/bad/path)，基本可断定 import 路径无效 - 检查对应
.go文件里的import语句：是否多写了/v2？是否把internal包误写成公开路径？ - 如果是从 fork 项目复制的代码，确认原项目是否改过模块路径（比如从
github.com/old/repo搬到了github.com/new/repo） - 别信 IDE 自动补全的路径——它可能缓存了旧的 module path，实际
go list -m查不到
go mod verify 报 checksum mismatch 但 go.sum 里有记录
说明本地缓存的 zip 包内容和 go.sum 记录的哈希不一致，原因通常是：包被作者篡改、代理镜像同步延迟、或你本地改过 vendor 内容却没更新 go.sum。
- 先运行
go clean -modcache清掉本地缓存，再go mod download - 如果仍失败，用
curl -s https://proxy.golang.org/github.com/some/pkg/@v/v1.2.3.info看官方记录的Sum是否和go.sum一致 - 不一致就说明镜像源有问题，临时切回官方 proxy：
go env -w GOPROXY=https://proxy.golang.org,direct - 一致但本地校验失败，说明你机器上的文件被修改过（比如手动解压改过代码），这时只能删掉
pkg目录重下
真正难搞的破损依赖，往往藏在间接依赖深处，靠 go list -m all 扫一眼就能暴露；而反复出现的“找不到模块”，十有八九是 GOPRIVATE 漏配或者 replace 写错路径——这些地方一旦出错，不会报具体哪一行错，只会让你在一堆 unknown 和空行里来回翻。
