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