go mod tidy 默认不扫描 *_test.go 文件，仅分析主构建可见的源码，因此测试依赖不会被自动识别或清理；需显式加 -test 参数或手动验证编译才能准确剥离。
go mod tidy 默认不扫描测试文件，除非你显式触发
默认情况下 go mod tidy 只分析当前构建环境能“看到”的 .go 文件——即满足当前 GOOS/GOARCH 且无排斥构建标签的普通源码。测试文件（*_test.go）**不会自动纳入依赖计算**，哪怕它们 import 了额外包。这意味着：你写了一堆 import "github.com/stretchr/testify/mock" 在 service_test.go 里，go mod tidy 运行时根本无视它，对应模块会保留在 go.mod 中。
常见误判现象：go mod tidy -v 输出里看不到任何 _test.go 路径，但 go test ./... 却能跑通——说明测试依赖是“悬浮”在 go.mod 里的，没被 tidy 清理，也没被主构建引用。
- 想让
go mod tidy看到测试依赖，必须加-modfile go.sum或确保当前 shell 的GOOS与测试文件中构建约束一致（比如// +build linux的测试在 macOS 下运行tidy就会被跳过） -
go test ./...执行时会临时拉取测试所需依赖，但这些依赖不会反向写入go.mod，除非你手动go get或之前运行过go mod tidy且测试文件被识别到了 - 最稳妥的验证方式：删掉
go.mod中疑似仅用于测试的模块，再跑go test ./...；如果失败，说明它确实被测试代码 import 了，不能删
用 go list -deps 检查测试代码的真实依赖树
go list 是比 go mod graph 更底层、更贴近实际编译行为的工具。它能告诉你哪些包真正在当前上下文中被解析为依赖，包括测试模式下的路径。
要精准剥离测试专用依赖，先确认它们是否真的只存在于测试场景：
立即学习“go语言免费学习笔记（深入）”；
- 运行
go list -deps -f '{{if not .Standard}}{{.ImportPath}}{{end}}' ./...—— 这会列出当前包及其所有递归依赖，但排除标准库；若输出里包含github.com/golang/mock之类，说明它已被主代码链引用，不是纯测试依赖 - 专门检查测试依赖：执行
go list -deps -f '{{if not .Standard}}{{.ImportPath}}{{end}}' ./... -test（注意末尾-test），这个命令强制进入测试模式，能暴露仅在_test.go中出现的导入 - 对比两次输出差异：只在
-test版本里出现的包，才是可安全剥离的目标；但要注意，有些包（如testing）虽在测试中 import，却是标准库，不会出现在go.mod中
剥离后必须验证测试能否编译通过，而非运行
删掉一个模块后，go test 可能直接报 cannot find package，但你未必需要立刻恢复它——因为真正要验证的是“测试代码能否编译”，而不是“能否执行”。这一步常被跳过，导致 CI 后续失败。
推荐用两种零开销方式验证：
-
go test -run NONE ./...：匹配不到任何测试函数，但完整走完编译流程；失败说明缺失的模块确实是测试编译必需的 -
go test -count=0 ./...：Go 1.14+ 支持，语义更明确；它甚至能捕获t.Helper()被误写在非测试函数里的语法错误，比-run NONE更严格 - 不要用
go build ./...验证——它默认忽略_test.go，完全测不到测试依赖
vendor 目录不会随 tidy 自动更新，残留测试依赖得手动清
go mod tidy 只改 go.mod 和 go.sum，对 vendor/ 目录完全无感。即使你已从 go.mod 中删掉了 github.com/onsi/ginkgo/v2，它仍静静躺在 vendor/ 里，可能误导新协作者或 CI 环境。
同步 vendor 的正确姿势不是 go mod vendor 一次了事：
- 先
rm -rf vendor/彻底清空，避免旧包残留 - 再
go mod vendor，它会严格按当前go.mod复制依赖；此时 vendor 中不再包含任何被 tidy 剥离的测试专用模块 - 如果项目使用
-mod=vendor构建，务必确认vendor/modules.txt与go.mod一致——该文件是 vendor 模式的权威清单，不一致会导致构建行为漂移
真正的难点不在命令本身，而在于判断某个模块是否“仅用于测试”：它可能被 //go:generate 调用、被构建标签隔离、或仅在 integration_test.go 中 import。这些场景下，go mod tidy 的默认行为就是“看不见”，剥离动作必须人工交叉验证，不能靠自动化假设。
