go mod tidy 不会自动删除陈旧模块，仅移除未被任何.go文件import且无间接依赖的模块；它依据当前构建标签下的实际导入语句判断，不处理反射、配置驱动、测试专用或条件编译中未启用的依赖，需人工验证。
go mod tidy 会自动删掉陈旧模块吗
不会自动删——但能精准识别并移除真正“陈旧”的模块。关键在于“陈旧”的定义：不是版本老，而是代码里没 import 它。比如你曾经用过 github.com/sirupsen/logrus v1.8.0，后来全换成 zap，且所有 .go 文件里都删掉了 import "github.com/sirupsen/logrus"，这时 go mod tidy 才会把它从 go.mod 中清除。
- 它只看当前构建标签下所有
.go文件的import语句，不关心 git 历史、注释或未启用的条件编译块（如//go:build ignore） -
// indirect标记的模块不会被删，除非它已彻底脱离依赖链（比如上游库升级后不再引用它） - 若模块被
replace覆盖，tidy仍会保留require行，但会校验replace目标是否有效；失效的replace会被清理
执行 go mod tidy 前必须确认的三件事
跳过检查容易误删或漏删，尤其在多 module 或含测试依赖的项目中。
- 所有
.go文件已保存，特别是刚删完 import 的文件——tidy读的是磁盘内容，不是编辑器缓存 - 确认当前工作目录是 module root（有
go.mod的目录），否则可能清理错地方 - 如果项目含子 module（如
cmd/xxx/go.mod），需分别进入对应目录执行go mod tidy，主目录的tidy不会递归处理它们
如何验证某个模块是否真被停用
别只看 go.mod 里有没有那行 require，得确认它是否还在依赖图里活着。
- 运行
go mod why -m github.com/old/module：输出unknown pattern表示已完全断连；若显示具体 import 路径，说明仍有代码在用它 - 对比
go list -m all | wc -l执行前后行数变化，下降才代表精简生效 - 手动 grep 检查：
grep -r "github.com/old/module" --include="*.go" .，结果为空才是安全删除信号
删完之后还跑不起来？常见陷阱
看似干净了，但构建失败或 panic，往往是因为“陈旧”模块其实还在暗处起作用。
- 测试文件（
*_test.go）里还 import 着旧模块——tidy默认处理测试，但如果你用了// +build !test这类排除标记，它就看不见 - 某些工具类库（如
golang.org/x/tools）被go命令本身间接依赖，即使你代码没用，go list -m all也会列出，这不是冗余，别手贱删 - IDE 缓存或
go.sum校验失败：删完立刻go build报checksum mismatch，先go clean -modcache再重试
模块停用不是删一行 require 就完事，本质是代码与依赖的一致性校验。最稳的做法永远是：改代码 → 删 import → go mod tidy → go build && go test 全通，缺一不可。
