不会。go mod tidy 默认不自动清理无用间接依赖，仅保留被直接 import 或被其他已保留依赖显式 require 的模块；需结合 go mod graph 和 go mod why 手动验证并删除冗余 require 行。
go mod tidy 会自动删掉无用间接依赖吗？
不会。默认情况下 go mod tidy 只确保 go.mod 中声明的依赖与实际 import 语句一致，但它**不会主动清理那些仍被其他依赖 transitively 引入、但当前模块没直接 import 的间接依赖**——哪怕你已经删掉了所有用到它的代码。
这类“残留”的间接依赖通常出现在以下场景：之前某个直接依赖引入了它，后来你升级或替换了该依赖，但 go.mod 里还留着旧的 require 条目；或者你手动加过 // indirect 标记却忘了清理。
-
go mod graph可以查出谁在引用它（比如go mod graph | grep github.com/some/old/pkg） - 如果输出为空，说明没人引用，它就是真正无用的
- 手动从
go.mod删除对应require行后，再跑一次go mod tidy，它不会自动加回来
怎么确认一个间接依赖是否真的被需要？
关键看两点：是否被当前模块 import；是否被某个直接依赖的 go.mod 显式 require（且版本不被覆盖）。只靠 go list -deps ./... 不够，它会把所有 transitive 依赖都列出来。
- 运行
go list -f '{{.ImportPath}} {{.Deps}}' ./...查当前包实际 import 的路径，过滤掉你怀疑的包名 - 检查它的上游依赖是否在
go mod graph中有边指向它；如果没有，且go mod why -m github.com/xxx/yyy返回main module does not depend on，基本可判定冗余 - 注意 vendor 下如果有该包，
go mod vendor会保留它，但go mod tidy不受 vendor 影响
go mod edit -dropreplace 和 -droprequire 能直接删依赖吗？
能，但要小心。这两个命令是修改 go.mod 的底层工具，不校验合法性，删错会导致 build 失败。
-
go mod edit -droprequire github.com/old/pkg直接删除该 require 行（包括// indirect） -
go mod edit -dropreplace old/path@v1.2.3删除 replace 规则，可能让间接依赖浮出水面 - 执行后必须立刻运行
go build ./...验证，否则 CI 可能因 missing package 报错 - 别对还在使用的依赖用
-droprequire——go mod why是唯一靠谱的依据
为什么 go.sum 里残留的校验和不能靠 tidy 清理？
因为 go.sum 记录的是所有曾经下载过的模块版本的 checksum，包括已被移除的间接依赖。它不是“当前依赖快照”，而是“历史下载记录”。go mod tidy 不动 go.sum 里的旧条目，除非对应模块在 go.mod 中彻底消失且未被任何现存依赖引用。
- 手动清理
go.sum很危险：删掉某行后，下次go get可能因 checksum 不匹配失败 - 安全做法是先确保
go.mod干净，再执行go mod tidy -compat=1.19（或你目标版本），它会自动 prune 不再需要的 sum 行 - 如果项目用了
GO111MODULE=off或 GOPATH 模式，go.sum行为更不可控，建议彻底切换到 module 模式
真正的难点不在命令怎么敲，而在判断“这个间接依赖到底算不算冗余”——它可能被某个深度嵌套的测试工具链悄悄用着，也可能只是上个版本遗留的幻影。动手前，go mod why 和 go mod graph 必须跑两遍。
