TestMain 是 Go 测试的唯一全局入口，接管所有测试执行流程，必须调用 m.Run() 和 os.Exit(code)，适合一次性重初始化（如数据库、容器），但不可用于单测隔离或共享包级变量。
TestMain 是测试的全局入口，不是可选补充而是关键控制点
Go 测试默认直接执行所有 Test* 函数，但一旦你声明了 func TestMain(m *testing.M)，整个测试流程就交由它接管——它成了唯一入口，所有其他测试（包括 Benchmark* 和 Example*）都必须经由 m.Run() 触发。不调用 m.Run()，测试函数一个都不会运行；不调用 os.Exit(code)，进程可能卡住或返回错误码 0（即使测试失败）。
-
TestMain在命令行参数解析前执行，如需读取 flag（比如-test.db=sqlite），必须手动调用flag.Parse() -
m.Run()内部会再次解析参数（含-timeout、-race等），所以你无需重复处理 - 它适合做一次性的重操作：启动本地 PostgreSQL 容器、创建临时目录、加载全局配置、初始化 Redis 连接池
- 切勿在
TestMain中修改包级变量并期望被各测试共享——并发执行下极易引发竞态（go test -race会报错）
func TestMain(m *testing.M) {
// setup：只执行一次
db, err := sql.Open("postgres", "user=test dbname=test sslmode=disable")
if err != nil {
panic(err)
}
if _, err := db.Exec("TRUNCATE users, orders"); err != nil {
panic(err)
}
// 执行全部测试
code := m.Run()
// teardown：只执行一次，无论测试是否 panic 都要保证清理
db.Close()
os.Exit(code)
}
TestMain 的清理逻辑必须幂等且防 panic 中断
如果某个测试触发 panic，TestMain 后续代码（比如 db.Close()）不会自动执行——这会导致连接泄漏、临时文件残留、端口占用等。不能依赖 defer（因为 TestMain 是普通函数，defer 只对当前函数生效，且 panic 时若未 recover 就会终止函数执行）。
- 把清理逻辑写在
m.Run()之后，并用defer包一层是无效的——别这么干 - 正确做法：用
recover()捕获 panic，确保清理执行；或改用更健壮的资源管理方式（例如事务回滚代替 TRUNCATE） - 清理操作本身也应幂等：比如
os.RemoveAll("/tmp/testdata")即使路径不存在也不报错；db.Exec("DROP TABLE IF EXISTS temp_log")比裸写DROP TABLE安全 - 数据库场景推荐用事务 + rollback：每个测试开始前开启事务，结束时 rollback，比清表更快、更隔离、不依赖 DB 权限
别用 TestMain 控制单个测试的生命周期
TestMain 是包级的，不是测试套件级的。如果你试图靠它“给每个 TestXxx 做独立 setup/teardown”，会掉进严重陷阱：所有测试共享同一份资源状态，命名顺序（TestA → TestB）不可靠，go test -count=2 会复用环境导致数据污染，t.Parallel() 更会让行为完全失控。
- 需要 per-test 隔离？用
defer+ 内存数据库（如sqlmock或entgo/db的 in-memory SQLite） - 需要一组相关测试共用环境（如“用户服务集成测试”）？用结构体封装
Setup()/Teardown()，并在每个顶层Test*中显式调用 - 需要步骤化流程（创建→更新→查询）？用
t.Run()子测试，而不是拆成多个顶级函数
TestMain 不等于 “测试前准备一切”，它只是调度器
很多人误以为 TestMain 是“测试初始化唯一正解”，结果把本该 mock 的 HTTP client、本该注入的 logger、本该用 t.Setenv 控制的环境变量，全塞进 TestMain 初始化，导致测试变慢、耦合变高、调试变难。
- 轻量依赖（如 config、logger、validator）应在测试函数内构造，或通过
testify/suite等辅助库组织 -
TestMain应只管“无法按需创建”的资源：真实 DB 连接、本地 gRPC server、S3 minio 实例等 - 如果初始化耗时超过 100ms，考虑加日志输出（
log.Printf("✅ DB ready in %v", dur)），方便排查超时问题 - CI 环境中，
TestMain初始化失败应 panic 而非 silent return，否则测试会跳过且报告为 PASS
TestMain 中的错误传播方式——它没有 *testing.T，不能 t.Fatal，只能 panic 或 os.Exit(1)；而 panic 若未被捕获，会丢失堆栈信息。建议统一用 log.Fatalf，既输出上下文又强制退出。 
