go mod tidy 默认扫描所有 .go 文件（包括 _test.go），但仅当测试文件满足当前构建标签条件时，其 import 才被计入依赖；它不区分生产与测试上下文，也不提供 --no-test 参数，需配合 go mod why -test 和 go list -deps 验证并手动 droprequire 处理纯测试依赖。
go mod tidy 默认不处理测试依赖
默认情况下，go mod tidy 会扫描所有 .go 文件（包括 *_test.go），但是否真正计入测试依赖，取决于当前构建环境是否“启用测试上下文”。它不会主动区分“生产”和“测试”，而是按实际 import 路径分析——如果 GOOS/GOARCH 不匹配某测试文件的 //go:build 标签，那里面的 import 就不会被识别。
常见现象：运行 go mod tidy 后，github.com/stretchr/testify 还留在 go.mod 里，但你确认主代码没引用它——大概率是因为某个 _test.go 文件 import 了它，且该文件能被当前环境构建（比如没加 //go:build !windows，而你正在 Linux 上 tidy）。
- 想让 tidy “看见”测试依赖，不需要额外参数；只要测试文件满足构建条件，它就会被扫描
- 想让 tidy “忽略”测试依赖，不能靠参数屏蔽，只能临时移除或重命名测试文件（不推荐）
- 更稳妥的做法是：先确保
go test ./能跑通，再运行go mod tidy -v，观察输出里是否有adding .../testify或类似行——有，说明它被识别为有效依赖
如何只保留生产依赖（剔除纯测试模块）
没有一键命令能“只留生产依赖”，因为 Go 没有内置的 --no-test 模式。但你可以用组合操作逼近目标：
- 先用
go list -deps -f '{{if not .Standard}}{{.ImportPath}}{{end}}' ./ | sort -u > deps-prod.txt获取当前主模块所有非标准库的显式+传递依赖（不含测试） - 再用
go list -deps -f '{{if not .Standard}}{{.ImportPath}}{{end}}' ./... | sort -u > deps-all.txt（注意./...包含测试文件）得到全量依赖 - 用
comm -13 deps-prod.txt deps-all.txt查出仅在测试中出现的模块，比如github.com/onsi/ginkgo/v2 - 对这些模块，执行
go mod edit -droprequire github.com/onsi/ginkgo/v2手动删掉 require 行
⚠️ 注意：-droprequire 只删 go.mod 中的声明，不校验是否真能删——删完必须立刻 go build ./ 和 go test ./ 验证，否则可能破坏测试运行。
为什么 go mod why -test 是关键判断依据
go mod why 默认不查测试路径，必须显式加 -test 才能暴露真实依赖来源。比如：
go mod why -test github.com/stretchr/testify/assert
如果返回：
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
main module does not need module
说明这个模块没被任何测试文件 import，极大概率是冗余残留，可安全 go mod edit -droprequire。
但如果返回：
your/module<br>your/module => github.com/stretchr/testify v1.8.4<br>github.com/stretchr/testify v1.8.4 => github.com/stretchr/testify/assert
那就说明它被主代码链式依赖了，哪怕你没直接 import，也不能删。
- 没加
-test的go mod why结果不可信——它可能显示“不需要”，只是因为没查测试分支 - 某些模块（如
golang.org/x/tools）常被go:generate引用，但go mod why -test查不到，得单独检查//go:generate行
容易被忽略的构建标签陷阱
测试依赖是否生效，高度依赖构建标签一致性。比如一个 integration_test.go 文件开头写了：
//go:build integration<br>// +build integration
那么只有当你运行 go mod tidy -tags=integration 或 GOFLAGS="-tags=integration" go mod tidy 时，里面的 import 才会被识别。否则 tidy 会把它当“死代码”，连带删掉对应模块。
- 跨平台项目要特别小心：Linux 下
go mod tidy不会看到//go:build windows的测试依赖，但 Windows 构建时会失败 - CI 环境中建议统一用
GOFLAGS="-tags=integration" go mod tidy，和实际测试命令保持一致 -
go list -f '{{.BuildConstraints}}' ./... | grep integration可快速定位哪些文件受该 tag 控制
真正难处理的不是“怎么删”，而是“删完后不同环境是否还能编译通过”——构建标签不一致导致的依赖漂移，比误删更隐蔽。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
