应使用 //go:build test 构建约束隔离测试依赖，配合独立 test/go.mod 或 go install 安装 CLI 工具；mock 需显式传递、及时清理；CI 测试推荐环境变量+构建标签组合控制。
测试时怎么避免把生产依赖带进 go test？
Go 的测试文件（*_test.go）默认和主包共享同一模块依赖，但很多测试工具（比如 testify、gomock、ginkgo）只该在测试时存在。直接 go get 到 go.mod 里，会导致生产构建多出无关依赖，还可能引发版本冲突。
正确做法是用 //go:build test + // +build test 构建约束，配合独立的 test 模块或 replace 隔离：
- 在测试文件顶部加两行构建注释：
//go:build test // +build test
，这样go build会跳过它，只有go test才加载 - 对应地，把测试专用依赖写在单独的
go.mod文件里（如test/go.mod），并在根目录go.mod中用replace ./test => ./test声明（仅限本地开发） - 更稳妥的方式：用
go install安装 CLI 类测试工具（如mockgen），不走go.mod依赖管理，彻底解耦
go test -tags 和 //go:build 哪个该用？
两者都能控制代码是否参与编译，但行为不同：//go:build 是 Go 1.17+ 推荐的正式语法，-tags 是运行时传参，只影响构建标签匹配，不改变源码可见性。
测试中常见误用是以为 go test -tags=integration 能让某个 integration_test.go 文件“自动生效”——其实不行，必须同时在该文件顶部写 //go:build integration，否则 go test 根本不会读它。
立即学习“go语言免费学习笔记（深入）”；
- 多个条件用空格分隔：
//go:build unit || integration - 排除某类测试用
!e2e，注意不能写成not e2e -
go test -tags=xxx只对已满足构建约束的文件起作用；如果文件没写//go:build，加 tag 也没用
Mock 数据库或 HTTP Client 时，为什么 sqlmock 和 httpmock 一跑就 panic？
典型原因是测试函数没清理资源，或者 mock 初始化顺序错了。比如 sqlmock.New() 返回的 *sql.DB 必须传给被测代码使用的 DB 实例，而不是直接替换全局变量——Go 没有“自动注入”，你得显式传递或通过接口抽象。
- HTTP mock 要在
TestXxx开头调用httpmock.Activate()，结尾用defer httpmock.DeactivateAndReset()，漏掉后者会导致后续测试复用旧 mock 规则 - SQL mock 如果用
db.QueryRow()却没提前注册ExpectQuery()，会 panic：“there is no stubbed expectation for this query” - 所有 mock 对象都该在
func TestXxx(t *testing.T)内部创建，别放在init()或包级变量里，否则并发测试会打架
如何让 go test 只跑特定环境下的测试（比如只在 CI 中跑集成测试）？
靠环境变量 + 构建标签组合最可靠。例如在 CI 脚本里设 ENV=ci，测试文件开头写：
//go:build ci && integration // +build ci,integration，然后运行
go test -tags="ci integration"。
- 不要依赖
os.Getenv("CI")做运行时跳过（t.Skip()），因为那样测试仍会被编译、计数，还可能因未初始化依赖而提前失败 - 如果集成测试需要真实数据库，用
if !strings.Contains(os.Getenv("TEST_ENV"), "integration") { t.Skip() }是次选，仅用于临时调试 - CI 环境下建议加
-timeout=30s和-race，防止死锁或竞态被忽略
测试依赖管理最难的不是加什么，而是删什么——每次删掉一个 mock 工具或测试辅助包后，记得检查 go mod graph | grep 输出，确认它真的没被任何 *_test.go 间接引用。否则 go test 依然会拉它进来。
