go test默认只运行单元测试，集成测试需用//go:build integration标签隔离并显式传参-go test -tags=integration ./...，且测试文件须与被测代码同包同目录、避免init()初始化真实依赖、禁用-race以防止假阳性。
go test 默认只跑单元测试，集成测试必须显式启用
Go 的 go test 命令默认忽略集成测试——这不是疏忽，是设计使然。集成测试依赖真实外部资源（DB、HTTP 服务、消息队列），本地或 CI 环境往往不具备，硬跑只会超时或 panic。
正确做法是用构建标签隔离：
- 在集成测试文件顶部加
//go:build integration（Go 1.17+）或// +build integration（旧版） - 文件名建议用
_integration_test.go后缀，比如order_integration_test.go - 运行时必须显式传参：
go test -tags=integration ./... - 日常开发用
go test -short ./...，配合测试函数开头的if testing.Short() { t.Skip(...) }快速跳过
测试文件必须和被测代码同包同目录，否则访问不了私有字段
Go 不靠路径或框架识别测试，只认两件事：文件名含 _test.go，函数名以 Test 开头且参数为 *testing.T。但它还隐含一个硬约束：测试文件必须和被测代码声明相同的 package，放在同一目录下。
常见踩坑点：
- 想测
internal/service/user.go，却把user_test.go放到cmd/目录 → 包名不一致，go test找不到，或报undefined: CreateUser - 测试文件写了
package main，但源码是package service→ 编译失败 - 试图在测试里直接访问结构体未导出字段（如
u.id）→ 只有同包才能访问，跨包只能走公开方法
Mock 失效的根本原因：全局变量或 init() 初始化了真实依赖
很多团队 mock 总是“看起来生效，一跑就错”，问题不在 mock 库，而在初始化时机。只要依赖（如 *sql.DB、http.Client）是在包级变量或 init() 函数里 new 出来的，测试之间就会互相污染，t.Cleanup 都救不回来。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
真正可控的解法只有两个：
-
接口注入：定义
DBExecutor接口，让业务逻辑依赖接口而非具体类型；测试时传入mockDB，生产传realDB - 构造函数参数化：服务初始化时，把所有外部依赖（DB、cache、HTTP client）都作为参数传入，main 函数里才 new 真实实例
- 绝对不要在
init()或包级变量里初始化任何带状态的 client
集成测试别开 -race，它会报一堆“假阳性”数据竞争
go test -race 对单元测试很友好，能揪出 goroutine 间共享变量的隐患。但集成测试常复用连接池、transport、全局缓存等——这些本就是设计为并发安全的，-race 一扫就报 data race，不是 bug，是预期行为。
稳妥做法：
- 单元测试放心开
-race，CI 脚本里明确写成go test -race -short ./... - 集成测试默认禁用
-race，CI 中单独跑：go test -tags=integration ./... - 真要排查某个集成测试里的竞态？删掉
-race，改用go run -gcflags="-l" -race your_test.go单独执行，再看是否复现
最易被忽略的是：集成测试里对数据库连接池、HTTP transport、Redis 客户端的复用，本质上是“共享状态”，-race 检测机制无法区分这是设计使然还是 bug。这时候得靠日志、压测和人工 review，而不是依赖工具告警。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
