TestMain 是 Go 中唯一能在所有测试前后执行自定义逻辑的入口，需定义在 main 包中、手动调用 m.Run() 并用 os.Exit(m.Run()) 传递退出码，适用于全局资源初始化与清理，但不适用于单测隔离场景。
TestMain 函数签名和基本用法
Go 的 TestMain 是唯一能让你在所有测试运行前后执行自定义逻辑的入口，但它不是自动生效的——必须手动调用 m.Run()，否则所有测试直接跳过。
- 函数签名固定为
func TestMain(m *testing.M)，必须定义在main包中（即测试文件里不能是其他包名） - 不调用
m.Run()就等于没跑测试，常见错误是只写了 setup/teardown 却忘了这句 -
m.Run()返回 exit code，应原样传给os.Exit()，否则测试进程可能异常退出（比如返回 0 即使有失败用例）
func TestMain(m *testing.M) {
// setup
os.Setenv("ENV", "test")
defer func() {
// teardown
os.Unsetenv("ENV")
}()
os.Exit(m.Run()) // 必须有
}
全局资源初始化与清理的典型场景
数据库连接、HTTP server 启停、临时目录创建等需要跨测试共享或一次性释放的资源，适合放在 TestMain 里处理；但要注意：它无法感知单个测试的失败状态，也不支持并发安全的 per-test 状态管理。
- 启动一个本地 HTTP mock server？用
http.ListenAndServe+defer srv.Close()，但得确保端口不冲突（建议用:0让系统分配） - 初始化 SQLite 内存数据库？可以，但注意多个测试并行时若共用同一
*sql.DB实例，需加锁或改用独立连接 - 写入临时文件？用
os.MkdirTemp("", "test-*")并在 defer 中os.RemoveAll()，别硬编码路径
TestMain 和子测试（t.Run）的协作边界
TestMain 管的是整个 go test 进程生命周期，而 t.Run 是单个测试函数内的嵌套控制；两者不嵌套、不通信，误以为能在 TestMain 里“拦截”某个子测试是常见误解。
- 不能在
TestMain中判断“当前要跑的是 TestFoo 还是 TestBar”——它没提供测试名称钩子 - 想对某组测试做特殊 setup？应该用单独的测试文件，或用
init()+ 全局变量标记，而不是强塞进TestMain - 如果用了
-run过滤测试，TestMain仍会完整执行一次，哪怕只跑一个用例
替代方案：什么时候不该用 TestMain
多数情况下，单测应该无状态、可重复、彼此隔离。TestMain 容易把测试变成“顺序敏感”甚至“状态残留”，尤其当团队开始写集成测试时，更容易滥用。
立即学习“go语言免费学习笔记（深入）”；
- 只是想在每个测试前重置一个 map？直接在
TestXxx开头写data = make(map[string]int)更清晰 - 需要 mock 时间或随机数？用
testify/mock或接口注入，而不是在TestMain里改全局time.Now - CI 环境里并行执行测试（
go test -p=4）时，TestMain的 setup/teardown 会被所有 goroutine 共享，容易引发竞态
真正需要 TestMain 的地方其实不多，一不小心就把它用成了“测试版 main 函数”，反而掩盖了设计缺陷。
