testmain 是 go 测试框架中唯一可接管整个测试生命周期的钩子函数，必须严格定义为 func testmain(m testing.m)、置于 _test.go 文件中且仅一个，m.run() 必须显式调用一次并透传返回值给 os.exit()，初始化在前、清理在后，需线程安全且可重入。
Go 测试中没有“测试主函数”这个概念，TestMain 不是 main 函数的测试版，而是 Go 测试框架提供的唯一可接管整个测试生命周期的钩子函数——它必须存在、必须写对，否则你看到的 “ok” 很可能只是假象。
TestMain 函数签名和位置为什么必须严格匹配
Go 测试框架只识别一种签名：func TestMain(m *testing.M)。漏掉指针星号（写成 testing.M）、多加返回值（比如 error）、函数名拼错（testmain 或 TESTMAIN），编译器都不报错，但 go test 会直接跳过所有 TestXxx 函数，静默退出。
它还必须定义在 *_test.go 文件中，且整个包只能有一个。多个文件都定义？编译报错：multiple definition of TestMain。
- 放在非测试文件（如
main.go）里，完全不生效 - 写在子包的
_test.go中，无法控制父包或项目级初始化——TestMain是 per-package 的 - 用
init()模拟全局 setup，结果测试没跑、init()却早执行完了，资源泄漏或状态错乱
m.Run() 必须显式调用且仅调用一次
m.Run() 不是建议调用，它是把控制权交还给测试调度器的唯一方式。不写这句，所有 TestXxx 都不会执行，go test 输出的耗时与状态码全是默认值，毫无参考价值。
它的返回值是整型退出码（0 表示成功，非 0 表示失败），必须透传给 os.Exit()。写成 return 0 或直接 os.Exit(0) 都不行——前者绕过测试框架的状态收集，后者可能让 CI 误判为“测试通过”。
- 不能在
m.Run()前panic，否则测试框架收不到任何信号，进程直接终止 - 不能在
defer里调用m.Run()，它必须是同步、显式、一次性的调用 -
m.Run()返回后，才表示所有TestXxx已结束（包括它们内部启动的 goroutine，但不保证已全部退出）
初始化放 m.Run() 前，清理必须写在 m.Run() 后
很多人以为在 TestMain 开头加个 defer cleanup() 就能兜底，其实不对。defer 在函数退出时才执行，而 TestMain 的生命周期覆盖整个测试进程：m.Run() 返回后函数还没退出，defer 还没触发。所以真正跨测试的清理逻辑，必须显式写在 m.Run() 之后。
更现实的问题是：初始化可能失败（DB 连不上、端口被占），你得提前退出，但已分配的部分资源仍需释放。稳妥做法是：
- 把清理逻辑封装成可重入函数（比如检查连接是否为
nil、目录是否存在再删） - 在初始化成功后，用
defer cleanup()应对 panic 场景 - 在
m.Run()返回后，再调一次cleanup()确保执行 - 清理函数内部做空指针/状态判断，避免重复关闭或删除不存在的资源
并发测试下全局资源必须线程安全
Go 默认并发运行测试（go test 不加 -p 1），但 TestMain 的初始化代码只执行一次。如果你在初始化阶段修改了包级变量（比如一个全局 db *sql.DB），而没控制并发安全，就可能被多个测试 goroutine 同时读写。
典型场景：集成测试中启动 httptest.Server 或连接数据库，这些资源本身是线程安全的，但你的包装逻辑（比如缓存、计数器、状态标记）不是。
- 用
sync.Once包裹初始化逻辑，比如once.Do(func(){}) - 避免在
init()函数里做需要 cleanup 的事，它无法配对释放 - 清理阶段不要依赖“所有测试已结束”的假设——
m.Run()返回后才是安全时机
最常被忽略的点是：TestMain 不是“可选增强”，它是 Go 测试框架中唯一能真实感知测试开始与结束边界的机制；一旦写错，问题不会报错，只会让你误以为测试通过了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
