Go项目中重复依赖源于模块路径冲突、间接依赖版本不一致或replace/exclude误用；表现为同一路径多版本共存，可用go list -m all或go mod graph定位，需手动统一版本并验证编译。
Go 项目里出现重复依赖，通常不是因为 go mod tidy 失效，而是模块路径冲突、间接依赖版本不一致或 replace / exclude 使用不当导致的。直接删 go.sum 或反复 go mod vendor 只会让问题更隐蔽。
怎么看是不是真有重复依赖？
Go 没有传统意义上的“重复类加载”，但重复体现在：同一模块被多个不同版本引入（比如 github.com/sirupsen/logrus v1.8.1 和 v1.9.3 同时出现在 go.mod 的 require 块中），或 go list -m -f '{{.Path}} {{.Version}}' all 输出里出现多行相同路径不同版本。
- 运行
go list -u -m all | grep -v "^\(golang.org\|std\|cmd\)"查看所有可升级/存在版本分歧的模块 - 用
go mod graph | grep 'module-name'定位谁在拉取旧版本（例如查gopkg.in/yaml.v2被谁间接引用） - 注意
indirect标记——它说明该依赖未被当前模块直接 import，但被其他依赖需要；这类容易成为版本撕裂点
为什么 go mod tidy 没清掉重复项？
go mod tidy 只保证最小可行依赖集，不强制统一版本。当两个不同主版本（如 v1 和 v2）被不同子模块 require，Go 会同时保留——因为它们是语义化版本隔离的独立模块（example.com/lib/v2 ≠ example.com/lib）。
- 检查
go.mod里是否混用了/v2和无后缀路径，这是常见根源 - 某些库（如
golang.org/x/net）在旧项目中被硬编码了 commit hash，而新依赖用 tag，导致 Go 认为是两个不同模块 -
replace指向本地路径或 fork 仓库时，若没同步更新下游依赖的 import path，也会造成“逻辑重复”
手动统一版本的实操步骤
目标是让所有对某模块的引用收敛到一个明确版本，而不是靠 tidy 猜。
立即学习“go语言免费学习笔记（深入）”；
- 先用
go get -u=patch module@version（如go get -u=patch github.com/sirupsen/logrus@v1.9.3）升级到指定补丁版，避免跳主版本 - 如果要降级，直接编辑
go.mod中对应require行，然后运行go mod tidy——不要只go get，否则可能残留旧版本 - 对必须共存的多主版本（如
v1和v2），确保代码里 import path 严格匹配（import "example.com/lib/v2"），别漏掉/v2 - 清理后跑
go build -o /dev/null ./...验证是否真能编译通过，有些“看似重复”其实只是go.sum里留着历史校验和
长期避免重复的关键习惯
重复依赖很少是某次操作引发的，更多是协作中缺乏约束的结果。
- CI 中加一步
go list -m all | awk '{print $1}' | sort | uniq -d，有输出就失败——这能捕获同名不同版本的 require - 禁用
replace除非必要；若必须用，配合//go:build条件编译或文档注明原因 - 团队内约定主版本升级流程：先改 import path，再改 go.mod，最后跑 test；不要跨 v1→v2 直接
go get -
go.sum不是垃圾，别删；它记录的是实际构建用到的每个 zip 校验和，删了会导致下次go mod download拉错内容
最麻烦的重复往往藏在测试依赖或 tools.go 这类伪主模块里——它们不参与构建，但会污染 go.mod，检查时容易漏掉。
