TestMain 是 Go 测试框架中用于全局初始化和清理的特殊函数，必须命名为 TestMain、参数为 *testing.M、返回 int 并调用 m.Run()；直接在 Test 函数中初始化会导致状态不一致、竞态和单测隔离性破坏。

TestMain 是什么，为什么不能直接在 Test 函数里初始化

TestMain 是 Go 测试框架提供的一个特殊函数，用于在所有测试运行前/后执行自定义逻辑。它不是必须的，但当你需要做全局初始化（如启动数据库、加载配置、设置环境变量）或清理（如关闭连接、删除临时文件）时，TestMain 是唯一可靠的方式。

直接在 TestXxx 函数里初始化的问题在于：每个测试函数都可能被单独运行（比如 go test -run TestFoo），而其他测试函数又可能依赖未初始化的状态；更严重的是，多个测试并发执行时，重复初始化或竞态清理会导致失败。Go 不保证测试函数的执行顺序，也不提供“before all”或“after all”的钩子——TestMain 就是这个角色的替代方案。

如何正确定义和使用 TestMain

必须满足三个条件，否则会被忽略：
• 函数名严格为 TestMain
• 参数类型为 *testing.M
• 返回 int 类型，并调用 m.Run()

常见错误包括：拼错函数名（如 TestMainn）、漏掉星号（写成 testing.M 而非 *testing.M）、忘记 return 或提前 return 0 导致测试不执行。

立即学习“go语言免费学习笔记（深入）”；

典型结构如下：

func TestMain(m *testing.M) {
	// 全局初始化
	setup()

	// 运行所有测试（阻塞，直到全部结束）
	code := m.Run()

	// 全局清理
	teardown()

	// 必须返回 code，否则 go test 认为失败
	os.Exit(code)
}

TestMain 中的并发与状态共享风险

Go 测试默认并发执行（-p 控制并行数），但 TestMain 只运行一次，且在所有测试开始前完成初始化。这意味着：你在 setup() 中创建的全局变量（如 db *sql.DB、mockServer *httptest.Server）会被所有测试共享——这本身没问题，但必须确保这些资源是线程安全的。

容易踩的坑：

• 在 setup() 中启动了 HTTP server，但没设 Handler 或监听地址冲突，导致后续测试 panic
• 用 os.Setenv 修改环境变量后，没在 teardown() 中恢复，影响其他包的测试行为
• 初始化了全局 map 或 slice，但在多个测试中直接修改，引发数据污染（比如 TestA 往 cache 写入 key，TestB 读到不该存在的值）
• 调用 m.Run() 后仍执行耗时操作，拖慢整个测试流程（清理应尽量轻量）

替代方案对比：TestMain vs. TestXXX setup/defer

对于单个测试内部的初始化，用 defer teardown() 更简单安全；但跨测试的状态管理必须用 TestMain。注意：Go 1.14+ 支持 t.Cleanup()，适合单测级别的资源回收，但它无法替代 TestMain 的全局生命周期控制。

真正需要 TestMain 的场景非常明确：

• 启动/关闭外部服务（PostgreSQL、Redis、MinIO）
• 生成并清理测试用临时目录（os.MkdirTemp + os.RemoveAll）
• 预加载大型配置或证书，避免每个测试重复解析
• 设置信号处理或全局日志 hook，且需在所有测试前后统一开关

如果只是打开一个内存数据库（如 sqlite.Open(":memory:")），其实更适合放在每个测试里——因为隔离性更好，调试也更清晰。别为了“看起来统一”而滥用 TestMain。