TestMain是Go测试框架中唯一能控制全部测试生命周期的全局入口，必须在需所有测试前初始化（如启mock服务）和测试后清理时使用；签名须为func TestMain(*testing.M) int，定义于_test.go中，且必须显式调用m.Run()并用其返回值调用os.Exit()。
TestMain 是什么，什么时候必须用它
TestMain 是 Go 测试框架提供的唯一允许在所有测试函数执行前后做全局初始化和清理的入口。它不是“可选优化”，而是当你需要：
- 在所有
Test*函数运行前启动一个共享的 mock 服务（比如本地 HTTP server、数据库连接池） - 确保某个环境变量或全局状态只设置一次，且在全部测试结束后还原
- 避免每个测试都重复调用
os.Setenv或sql.Open导致资源泄漏或竞态
如果不使用 TestMain，而是在每个测试里手动 init/cleanup，容易漏掉 defer、panic 时未执行 cleanup、或并发测试下状态污染。
如何正确声明和调用 m.Run()
TestMain 必须定义在包级，函数签名严格为 func TestMain(m *testing.M)，且必须显式调用 m.Run() 并返回其结果。漏掉 m.Run() 会导致所有测试静默跳过——这是最常踩的坑。
func TestMain(m *testing.M) {
// 初始化：比如启动 mock server
srv := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
w.WriteHeader(200)
w.Write([]byte("ok"))
}))
defer srv.Close() // ⚠️ 错！这里 defer 不会等到所有测试结束
<pre class="brush:php;toolbar:false;">// 正确做法：在 m.Run() 后清理
code := m.Run()
// 清理：此时所有 Test* 已执行完毕
srv.Close()
os.Exit(code)}
注意三点：
-
m.Run()必须被调用，且返回值要传给os.Exit() - 所有初始化放在
m.Run()前，所有清理放在m.Run()后 - 不要用
defer做全局清理，它会在TestMain函数退出时立即触发，而非测试全部结束之后
多个测试文件共用同一套初始化时要注意什么
Go 的 TestMain 是 per-package 的，一个包里只能有一个 TestMain 函数。如果你在多个 _test.go 文件里各自定义了 TestMain，编译会报错：multiple definitions of TestMain。
常见误操作：
- 把
TestMain复制到每个测试文件里（错误） - 在子目录中建独立包，但没意识到它们不属于同一 package（导致初始化不共享）
正确做法：
- 所有需要共享初始化的测试必须在同一 package 下（比如都放在
pkgname_test包） - 如果确实需要跨 package 初始化（如集成测试），改用外部 shell 脚本启动依赖服务，或用
init()+ 环境变量控制，但无法保证 cleanup 时机
TestMain 中 panic 或 os.Exit 会破坏测试流程
TestMain 内部如果发生 panic，或调用了 os.Exit()（除了最后那个），会导致整个测试进程提前终止，后续测试完全不运行，且 go test 返回码不是标准的 1（失败）或 0（成功），而是你指定的任意值——CI 工具可能误判为“中断”而非“失败”。
避免方式：
- 初始化失败时不要 panic，改用
log.Fatal或直接os.Exit(1)，但确保这发生在m.Run()之前 - 清理阶段尽量不 panic；若必须检查清理结果，用
log.Printf记录，不要中断流程 - 不要在
m.Run()前调用任何可能 panic 的测试辅助函数（比如未加recover的第三方 mock 初始化）
真正难处理的是：当初始化依赖外部服务（如 Redis 连接），超时后是该跳过所有测试，还是让每个测试自己重试？前者靠 TestMain 控制，后者就得放弃全局初始化——这个权衡点很容易被忽略。
