不是必须，但绝大多数真实场景下必须用TestMain；它是唯一能串行控制测试生命周期、安全启停外部依赖（如DB、HTTP服务）并避免测试污染的入口，需严格遵循签名和清理规范。
Go集成测试必须用TestMain吗？
不是必须，但绝大多数真实场景下你得用。不写TestMain，就很难在所有测试开始前启动数据库、HTTP服务或清理临时目录——这些操作一旦放在单个TestXxx函数里，要么重复执行拖慢速度，要么顺序错乱导致测试间污染。
Go的测试框架默认并行执行TestXxx函数，而TestMain是唯一能串行控制整个测试生命周期的入口。它不是“高级技巧”，而是集成测试的事实标准起点。
-
TestMain必须定义在func TestMain(m *testing.M)签名下，且只能有一个 - 必须显式调用
m.Run()，否则所有测试都不执行（静默跳过，极易误判为“没写测试”） - 不能在
TestMain里直接用t.Log或t.Fatal——*testing.M没有testing.T的方法 - 如果要提前退出（比如DB连接失败），用
os.Exit(code)，别用return
如何用TestMain安全启动和关闭外部依赖
核心原则：初始化失败就立刻退出，成功后务必确保清理逻辑被执行（哪怕测试 panic 了）。靠defer + os.Exit组合容易漏掉清理，推荐用defer注册清理函数，再用runtime.Goexit()或os.Exit收尾。
常见错误是把清理逻辑只写在TestMain末尾——一旦m.Run()中途崩溃，后面代码根本不会跑。
立即学习“go语言免费学习笔记（深入）”；
- 启动DB时检查
ping，超时或认证失败立即os.Exit(1) - 用
tempfile创建测试专用目录，defer os.RemoveAll(dir)放最开头 - 启动HTTP服务用
httptest.NewUnstartedServer，避免端口冲突；启动后记得srv.Start()，结束时srv.Close() - 环境变量修改（如
os.Setenv）必须配对os.Unsetenv或os.Clearenv，否则污染后续测试
func TestMain(m *testing.M) {
db, err := sql.Open("sqlite3", ":memory:")
if err != nil {
log.Fatal(err)
}
defer db.Close()
<pre class="brush:php;toolbar:false;">// 清理逻辑必须放这里，不是m.Run()之后
defer func() {
_, _ = db.Exec("DROP TABLE IF EXISTS users")
}()
os.Exit(m.Run())}
go test运行集成测试时为什么总报错找不到模块或配置？
因为集成测试常依赖main包外的初始化逻辑（比如init()函数加载配置），而go test默认只编译测试文件所在包，不会自动拉取cmd/或internal/下的启动代码。
更隐蔽的问题是：本地go run main.go能读到.env，但go test默认不加载它——环境隔离是常态，不是bug。
- 不要在
TestMain里硬编码路径如"../config.yaml"，改用filepath.Join("..", "config.yaml")并检查os.Stat - 配置加载失败时，打印具体缺失的文件路径，而不是笼统说“config not found”
- 用
-tags=integration标记集成测试，配合// +build integration注释，避免CI误跑 - CI环境缺少
docker或redis-cli时，exec.LookPath("redis-cli")会返回error，需提前判断并跳过测试
为什么TestMain里启动的服务在测试中访问不到？
最常见原因是监听地址写死了"localhost:8080"，但测试里用http.Get("http://127.0.0.1:8080")——IPv4/IPv6栈差异、Docker网络、macOS的localhost解析异常都会导致连不上。
另一个高频坑是：服务启动了，但没等它真正ready就发请求，结果得到connection refused。
- 服务监听地址统一用
":0"让系统分配空闲端口，然后从srv.Listener.Addr().(*net.TCPAddr).Port取真实端口 - 发HTTP请求前加简单健康检查循环：
for i := 0; i - 避免在
TestMain里用log.Printf输出服务地址——测试日志可能被截断，改用fmt.Fprintf(os.Stderr, "...") - 如果用Docker Compose启依赖，
TestMain里别直接exec.Command("docker-compose", "up", "-d")，要等docker-compose ps | grep "Up"稳定后再继续
集成测试最难的从来不是写TestMain，而是让所有外部依赖在任意机器、任意时刻都处于“刚好可用又刚好干净”的状态——这个状态必须靠显式检查和防御性等待来维持，没法靠运气。
