TestMain 是 Go 测试框架中唯一能控制整个测试生命周期的入口函数，用于所有测试前初始化（如启动服务）和结束后清理（如关闭连接），必须定义为 func TestMain(m *testing.M)，且需手动调用 m.Run()。
Go TestMain 是什么，什么时候必须用
当测试需要在所有 Test* 函数运行前做一次全局初始化（比如启动数据库、加载配置、设置环境变量），或在全部测试结束后做一次清理（比如关闭连接、删除临时文件），就不能只靠每个测试里的 Setup/Teardown 了——TestMain 就是为此设计的入口函数。
它不是可选的“高级技巧”，而是 Go 测试框架明确支持的、唯一能控制整个测试生命周期的机制。没写 TestMain 时，Go 会自动调用默认逻辑；一旦定义了，就必须手动调用 m.Run()，否则所有测试都不执行。
如何正确声明和使用 TestMain
TestMain 必须定义在 func TestMain(m *testing.M) 形式，且放在 _test.go 文件中。它不能带其他参数，返回值必须是 int（用于向操作系统传递退出码）。
- 必须调用
m.Run()，它会执行全部Test*函数，并返回整型退出码 - 初始化代码写在
m.Run()前，清理代码写在m.Run()后 - 不能在
TestMain中直接调用os.Exit()，应返回m.Run()的结果或自定义状态码 - 如果初始化失败，可以提前 return 非零值（如
return 1），此时测试不会运行
示例：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
func TestMain(m *testing.M) {
// 初始化：启动 mock HTTP server
server := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
w.WriteHeader(200)
w.Write([]byte(`{"ok":true}`))
}))
defer server.Close()
// 设置全局变量或环境
os.Setenv("API_BASE", server.URL)
// 运行所有测试
code := m.Run()
// 清理：此处逻辑会在所有测试结束后执行
// （注意：defer 不适用于跨测试生命周期的清理，这里必须显式写）
os.Unsetenv("API_BASE")
os.Exit(code)
}
TestMain 和 init() / TestXxx 中 setup 的区别
init() 在包加载时执行，早于任何测试，但无法感知测试上下文，也不能做依赖 *testing.T 的操作（比如 t.Log 或跳过测试）；而 TestMain 是唯一能安全协调“全部测试前后”的钩子。
每个 TestXxx(t *testing.T) 内部的 setup 只作用于单个测试，适合隔离性要求高的场景（比如临时目录、内存 DB 实例）；但像启动一次 Postgres 容器、读取一次大配置文件这种开销大的操作，重复做就是浪费。
-
init()：无上下文，不可失败重试，不适合需*testing.T的操作 - 每个
TestXxx内 setup：强隔离，但可能低效 -
TestMain：一次初始化 + 一次清理，适合跨测试共享资源，但要自己处理并发/竞态（比如多个测试并发访问同一 DB 连接）
容易踩的坑和兼容性注意点
TestMain 看似简单，实际几个细节不注意就会让测试静默失败或行为异常：
- 忘记
return或写错os.Exit(code)—— 测试跑完没退出，CI 卡住 - 在
m.Run()前 panic，会导致测试框架无法捕获，输出混乱 - 在
TestMain里调用t.Skip()或t.Fatal()——*testing.T不可用，编译不过 - 并行测试（
t.Parallel()）下，若共享资源没加锁或没做线程安全设计，会出现数据污染 - Go 1.14+ 支持
-test.count=N多次运行测试，但TestMain仍只执行一次 —— 别假设每次go test都会重进TestMain
最常被忽略的是：清理逻辑必须放在 m.Run() 之后、os.Exit() 之前，且不能依赖 defer —— 因为 defer 在函数返回时才触发，而 m.Run() 可能已通过 os.Exit 终止进程，导致清理永远不执行。
