测试依赖会出现在go.mod中是因为go mod tidy将_test.go中的import视为有效引用；可通过隔离测试文件、使用独立子模块或移除不必要的import来避免污染主模块require列表。
go test 时引入的依赖为什么会在 go.mod 中出现
测试文件（_test.go）里的 import 会被 go mod tidy 当作有效引用处理，只要它参与当前构建标签（如默认构建、go:test 等），就会被纳入依赖图。这意味着你写在测试里的第三方断言库（比如 github.com/stretchr/testify）、mock 工具（github.com/golang/mock）甚至测试用的 HTTP 客户端封装，都会出现在 go.mod 的 require 列表里——哪怕生产代码完全不碰它们。
如何让测试依赖不污染主模块的 require 列表
Go 没有“devDependencies”概念，但可以通过构建约束和模块结构隔离：
- 把所有测试专用依赖的 import 放到单独的
*_test.go文件中，并确保这些文件不被主包（非_test）导入 - 避免在
main或业务包中 import 测试相关包；否则go mod tidy会认为它是运行时依赖 - 如果项目允许，把集成测试或 e2e 测试放到独立子模块（如
./e2e），里面有自己的go.mod—— 这样它们的依赖完全不进主模块 - 不要用
// +build !test之类方式试图“屏蔽”测试依赖，Go 的静态分析仍会扫描它；真正起作用的是构建标签是否启用，而go mod tidy默认启用所有标签
go mod tidy 会保留测试依赖，但可识别为 indirect
go mod tidy 不会删掉测试依赖，但它会判断：如果某个模块只被 _test.go 引入，且未被任何非测试代码引用，它会被标记为 // indirect。这不是错误，而是 Go 的正常行为——说明该模块是间接依赖，不是你主代码链的一部分。
你可以用以下命令确认哪些是纯测试依赖：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
go list -m -f '{{if and .Indirect (not .Main)}}{{.Path}} {{.Version}}{{end}}' all
输出里出现的 github.com/stretchr/testify 或 gotest.tools 就属于这类。它们不影响生产构建，但会出现在 go.sum 中，必须提交。
想彻底移除测试依赖？只能删代码或改结构
没有魔法开关能“排除测试依赖”。go mod tidy 的逻辑很实在：只要 import 存在且构建可见，就视为需要。所以真正可控的操作只有：
- 删掉测试文件中不必要的 import（比如用标准库
reflect.DeepEqual替代testify/assert） - 把重度测试依赖抽成独立的
cmd/testutil模块，用replace指向本地路径，再在 CI 中按需构建 - 用
go mod graph | grep 'test'查看谁在拉入测试库，再顺藤摸瓜定位源头
别碰 exclude 指令来“屏蔽”测试依赖——它针对的是版本冲突，不是用途分类，滥用会导致校验失败或构建不一致。
