testmain不会被自动调用，因go测试框架要求其必须定义在main包且签名严格为func(*testing.m)；常见错误包括包名非main、函数名大小写错误、未导入testing或参数类型错误。
TestMain 函数为什么没被自动调用
Go 测试框架不会自动发现或注册 TestMain，它必须严格满足两个条件：定义在 main 包中、函数签名完全匹配 func(*testing.M)。常见错误是把它写在非 main 包（比如 utils_test.go 里包名还是 utils），或者参数类型写成 *testing.T 或漏掉指针符号。
- 确保文件顶部是
package main，哪怕只是测试入口文件 - 函数名必须是
TestMain，大小写敏感，不能是testMain或MainTest - 必须 import
"testing"，且参数类型是*testing.M，不是testing.M（值传递会导致无法控制退出码）
如何用 TestMain 做全局初始化和清理
TestMain 的核心价值在于它包裹所有测试的生命周期：你可以在 m.Run() 前做初始化（如启动 mock server、连接数据库、设置环境变量），在之后做清理（关闭连接、删除临时目录、恢复全局状态）。但要注意——它只运行一次，不随每个 TestXxx 重复执行。
- 初始化失败时，直接
os.Exit(1)，不要依赖m.Run()返回值来判断是否继续 - 清理逻辑必须放在
defer或m.Run()之后，否则测试崩溃时可能跳过 - 避免在初始化中调用
t.Log或t.Fatal，*testing.M没有这些方法；改用fmt.Fprintln(os.Stderr, ...)
示例：
func TestMain(m *testing.M) {
os.Setenv("APP_ENV", "test")
db, err := setupTestDB()
if err != nil {
fmt.Fprintln(os.Stderr, "failed to setup DB:", err)
os.Exit(1)
}
defer db.Close()
os.Exit(m.Run())
}
TestMain 和 TestXxx 的执行顺序与并发影响
Go 默认并行执行测试（go test -p 控制并发数），但 TestMain 是串行且全局唯一的——它先于所有 TestXxx 执行，且所有测试共享同一轮初始化结果。这意味着：如果多个 TestXxx 并发修改了全局变量或共享资源（比如一个全局 map），TestMain 里的初始化无法帮你规避竞态。
立即学习“go语言免费学习笔记（深入）”；
- 不要在
TestMain初始化中创建非线程安全的共享状态（如未加锁的全局 slice） - 若测试本身需隔离状态，初始化应移到每个
TestXxx内部，或用t.Cleanup()配合局部 setup -
go test -race仍能检测出TestMain启动的 goroutine 与其他测试间的竞态
替代方案：什么情况下不该用 TestMain
多数场景其实不需要 TestMain。比如单个测试前后的 setup/teardown、HTTP client 配置、临时文件创建，用 TestXxx(t *testing.T) + t.Cleanup() 更轻量、更隔离、更易调试。滥用 TestMain 容易把测试耦合进全局状态，导致本地单测通过、CI 失败，或测试顺序敏感。
- 需要为每个测试单独初始化（如不同数据库事务、不同用户上下文）→ 放在
TestXxx函数体内 - 只想 mock 一个函数行为 → 用
monkey.Patch或接口注入，而非改全局变量 - 初始化耗时长但只部分测试需要 → 考虑
testify/suite或自定义子测试t.Run()分组
真正绕不开 TestMain 的情况很少：比如必须预加载 C 共享库、绑定固定端口的集成测试套件、或需要精确控制进程退出码的 CLI 工具测试。
