TestMain 是 Go 中唯一能接管全部测试流程的函数，必须在需全局初始化或清理时使用；定义后须显式调用 m.Run() 并用其返回值调用 os.Exit()，否则测试不执行。
TestMain 是什么，什么时候必须用它
TestMain 是 Go 测试中唯一能接管整个测试流程入口的函数。它不是用来跑单个测试用例的，而是当你的测试需要在所有 TestXxx 函数执行前做全局初始化（比如启动数据库、加载配置、设置环境变量），或在全部测试结束后做清理（比如关闭连接、删除临时文件）时才真正有用。
不写 TestMain，Go 会默认用内置逻辑跑所有测试；一旦你定义了它，就必须显式调用 m.Run()，否则所有测试都不会执行——这是最常踩的坑。
常见使用场景包括：
- 需要在测试开始前启动一个本地 Redis 或 PostgreSQL 实例
- 依赖外部服务且需复用连接池，避免每个
TestXxx都新建/销毁 - 要控制测试并发行为（比如强制串行运行某些资源敏感测试）
- 需捕获测试整体的退出码或统计耗时
如何正确声明和使用 TestMain
TestMain 必须是包级函数，签名固定为 func TestMain(m *testing.M)，且只能有一个。它不能带其他参数，也不能返回值。
关键点在于：你必须手动调用 m.Run()，并用其返回值作为 os.Exit() 的参数，否则测试进程不会正常退出。
func TestMain(m *testing.M) {
// 初始化：比如打开数据库连接
db, err := sql.Open("sqlite3", ":memory:")
if err != nil {
log.Fatal(err)
}
defer db.Close()
// 运行所有 TestXxx 函数
code := m.Run()
// 清理：比如关闭连接、释放资源
db.Close()
os.Exit(code)
}
注意：defer 在 TestMain 中的行为和普通函数不同——它会在 m.Run() 返回后、os.Exit() 前执行，所以适合放清理逻辑。
TestMain 和 init()、TestXxx 的执行顺序
Go 测试的初始化流程是线性的：先执行包的 init() 函数（如果有），再进入 TestMain，最后才是各个 TestXxx。
init() 函数（如果有），再进入 TestMain，最后才是各个 TestXxx。
这意味着：
-
init()适合做纯静态初始化（比如注册类型、设置全局变量），但无法访问*testing.M或控制测试生命周期 -
TestMain可以做带副作用的初始化（如启动子进程、监听端口），也能决定是否跳过某些测试（通过修改os.Args或提前os.Exit(0)） - 每个
TestXxx仍各自独立运行，彼此不共享状态，除非你主动用包级变量传递
特别注意：如果多个测试文件都定义了 TestMain，go test 会报错 multiple definitions of TestMain。它只能在一个文件里存在。
TestMain 的局限性和替代方案
TestMain 虽然强大，但也有明显限制：它无法按测试分组做初始化（比如只对 TestHTTP* 初始化 server），也不支持并行测试中的隔离初始化。
更轻量、更推荐的做法是：
AI舌诊面诊问诊医疗系统+诊疗商城系统源码
下载
AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。
- 用
TestXxx内部的setup/teardown模式（比如用t.Cleanup()）处理单测独占资源 - 对共用资源（如内存数据库）用 sync.Once + 包级变量 +
t.Helper()封装懒初始化 - 需要跨测试共享状态时，优先考虑无状态设计或用临时目录 + 随机端口避免冲突
TestMain真正不可替代的场合其实不多，多数时候是过度设计。它最容易被忽略的一点是：一旦用了，你就得自己负责整个测试生命周期——包括信号处理、超时控制、甚至 panic 捕获（默认不捕获）。
