go mod tidy 默认不清理测试专用依赖，因为它仅基于主构建路径的 import 语句分析依赖，而 *_test.go 中的 import 不参与主模块依赖计算；需配合 -test 参数使用 go mod why 验证，并通过 go test ./... 和 go mod tidy -v 协同清理。
go mod tidy 为什么删不掉测试专用依赖
它默认只看 import 语句是否出现在非测试文件里，而 _test.go 文件里的 import 不会被计入“主模块需要”，但也不会被自动清理——除非你显式告诉它要处理测试依赖。
常见现象：执行 go mod tidy 后，go.mod 里仍残留 github.com/stretchr/testify、golang.org/x/tools 这类明显只用于测试的模块；go list -m all | wc -l 数值没变，说明它们被当成了“有效依赖”。
-
go mod tidy默认忽略测试文件的 import，所以不会因测试文件引用而添加依赖，但也不会因测试文件引用而删除依赖 - 若某模块既被主代码引用、又被测试引用，
go mod tidy会保留它——哪怕主代码早已删了引用，只要测试还在用，它就留着 -
go mod why -m xxx不加-test参数时，返回(main module does not need module)是安全信号；但加了-test才能看到它是否仅被测试驱动
用 go mod why -test 确认依赖是否纯测试用途
这是最直接的验证方式。很多开发者只跑 go mod why golang.org/x/net，看到“not needed”就删，结果 CI 编译失败——因为那个包其实在 integration_test.go 里被用了。
正确做法是补上 -test 标志：
go mod why -m github.com/stretchr/testify -test
如果输出类似：
# github.com/stretchr/testify test/main_test.go:5:2: import "github.com/stretchr/testify/assert"
那就确认它是纯测试依赖；如果返回 (main module does not need module) 且无路径输出，才说明连测试也没用它。
- 必须加
-test，否则go mod why只查主构建图，完全看不见测试路径 - 对
//go:build integration或//go:build e2e这类标签限定的测试，需确保当前环境启用对应构建 tag（如GOFLAGS=-tags=integration go mod why -test） - 空白导入
import _ "net/http/pprof"若只在_test.go中出现，go mod why -test也能定位到
手动清理测试依赖的可靠操作顺序
别直接删 go.mod 里的 require 行——Go 工具链可能在下次 go test 时自动加回来，而且容易漏掉间接依赖。
推荐分步执行：
- 先跑
go test ./...确保所有测试通过，避免误删导致测试失败 - 对每个疑似测试依赖，运行
go mod why -m xxx -test验证路径 - 确认无主代码引用后，执行
go get -d -t ./...（-t表示包含测试依赖），再跟一次go mod tidy - 若仍残留，用
go mod edit -droprequire=xxx强制移除，然后go mod tidy -v观察是否重新拉入
go mod tidy -v 输出里出现 removing unused xxx 才算真正清理干净；如果紧接着又出现 adding xxx // indirect，说明它被其他依赖传递引入，得顺藤摸瓜查 go mod graph | grep xxx。
CI 构建中测试依赖容易被忽略的关键点
本地 go mod tidy 干净 ≠ CI 安全。很多项目在 CI 里跑 go build ./... 就认为没问题，但实际发布时用的是 go test -short ./... 或集成测试，这些场景会触发不同依赖集。
- CI 脚本里必须显式包含
go test ./...或至少go test -run=^$ ./...（空匹配，只编译不运行），否则测试依赖不会被加载校验 - 交叉编译（如
GOOS=linux go build）可能让某些带构建 tag 的测试依赖失效，导致go mod tidy误删——需在相同环境重复验证 -
replace指向本地测试工具（如replace github.com/example/testutil => ./internal/testutil）在 CI 中不可用，必须提前清理或改用indirect方式管理
测试依赖不是“无关紧要的”，尤其当它参与 pprof、benchmark 或 mock 初始化时，删错一行就可能让线上监控失能或压测脚本崩溃。验证动作必须覆盖构建、测试、交叉编译三类上下文，缺一不可。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
