TestMain 必须显式调用 m.Run() 才能执行测试，否则测试不运行；需用 os.Exit 非零码处理初始化失败；不可用 t. 方法；并发下只执行一次，须注意资源竞争与清理。
TestMain 函数必须手动调用 testing.M.Run() 才会真正执行测试
很多人写完 TestMain 发现测试不跑、或者初始化代码没生效，根本原因是忘了在函数体里调用 m.Run()。Go 的测试框架不会自动帮你调这个——它只负责把控制权交给你，剩下的全靠自己。
常见错误现象：go test 直接退出，零测试用例运行；或 init 代码执行了，但所有 TestXxx 函数完全没被调用。
- 必须在
TestMain函数末尾（或唯一出口路径）显式调用m.Run() - 不能提前 return，否则测试流程中断，
m.Run()永远不执行 - 如果需要在测试前后加逻辑，得包在
m.Run()前后，比如：func TestMain(m *testing.M) { setup() code := m.Run() teardown() os.Exit(code) }
全局初始化失败时，要通过 os.Exit() 传递非零状态码
测试进程启动阶段出错（比如数据库连不上、端口被占），不能靠 panic 或 log.Fatal —— 这会让 go test 报 “signal: killed” 或 “exit status 2”，而不是清晰的失败原因。
使用场景：加载配置、启动 mock server、准备测试数据库 schema。
AI舌诊面诊问诊医疗系统+诊疗商城系统源码
下载
AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。
- panic 会导致进程异常终止，
m.Run()不再有机会执行，且返回码不可控 - 应该用
log.Fatal或直接os.Exit(1)，确保测试框架收到明确失败信号 - 注意：不要用
os.Exit(0)，那会被当成“测试成功”，掩盖真实问题
TestMain 中不能依赖 *testing.T，也不该调用 t.Helper() / t.Cleanup() 等
TestMain 是进程级入口，不是测试函数，它的参数是 *testing.M，没有 *testing.T 实例。试图在里面用 t.Log 或 t.FailNow() 会编译报错或 panic。
容易踩的坑：想在初始化阶段记录日志或标记失败，结果误用了测试函数专属 API。
- 日志统一用
log.Print/fmt.Println，别碰任何以t.开头的方法 -
t.Cleanup()这类绑定到单个测试生命周期的机制，在TestMain里无意义，也不存在对应上下文 - 如果初始化逻辑本身需要测试（比如 config 加载是否正确），应单独写
TestLoadConfig，而不是塞进TestMain
并发测试下，TestMain 初始化只运行一次，但要注意资源竞争
哪怕你用 -race 或 -count=3 多次运行测试，TestMain 也只执行一次——这是它的设计本意。但这也意味着：如果你在初始化里创建了共享资源（如全局 map、临时文件句柄），而多个测试又并发读写它们，就可能触发 data race。
性能影响：初始化耗时长的逻辑（如拉镜像、启容器）会拖慢整个测试套件启动，且无法并行分摊。
- 避免在
TestMain里做可并行化的准备工作；更适合放到每个测试的Setup函数中 - 若必须共享状态（如共用一个 mock HTTP server），确保加锁或用 sync.Once 控制初始化时机
- 临时目录、端口号等易冲突资源，建议用
os.MkdirTemp+ 随机端口，别硬编码/tmp/testdata或:8080
