go中不能测试main函数，testmain仅用于测试包的一次性初始化和清理，必须定义在_test.go文件中且包名非main，签名须为func testmain(*testing.m)，并调用m.run()后return其返回值。
Go 里没有“测试 main 函数”这回事——main 函数本身不能也不该被直接单元测试；真正该用 TestMain 的场景，是为整个测试包做一次性的初始化和清理，比如启动 mock 服务、连接数据库、设置全局状态等。
为什么不能在 main 包里写 TestMain
常见错误：go test 报错 cannot define TestMain in package main。这是因为 TestMain 只能在测试文件（即文件名以 _test.go 结尾）中定义，且对应包名必须是 xxx_test，绝不能是 main。
- 如果你的业务逻辑写在
main.go里，先把它拆到独立包（比如cmd/或app/），再为那个包写xxx_test.go -
main包本身只负责调用入口，不承载可测逻辑；测它等于测整个进程生命周期，不可靠也不必要 - 想验证命令行行为？改用
os/exec.Command启动子进程并断言 stdout/stderr
TestMain 必须满足的签名和执行约束
TestMain 不是普通函数，它是测试框架识别的固定钩子，签名错一点就失效：
- 函数名必须是
TestMain，大小写敏感，不能加前缀后缀 - 参数类型必须是
*testing.M（不是testing.M，也不是m testing.M） - 必须调用
m.Run()，且必须显式return其返回值（通常是os.Exit(code)） - Go 1.14+ 起，漏掉
m.Run()或没return会导致测试卡死或 panic
错误写法示例：func TestMain(m testing.M) { ... }（少了指针）、defer m.Run()（不能 defer）、m.Run(); os.Exit(0)（忽略实际退出码）。
setup 和 teardown 的正确时机与陷阱
很多人把 defer cleanup() 放在 m.Run() 前面，结果 cleanup 在所有测试开始前就被执行了——这是对 defer 执行时机的误判。
-
defer在当前函数 return 时触发，而m.Run()是阻塞调用，等所有TestXxx执行完才返回 - 所以
defer cleanup()放在m.Run()后面，才能确保它在全部测试结束后执行 - 前置失败（如端口被占、配置缺失）应直接
os.Exit(1)，避免继续跑测试浪费时间 - 不要在
init()里做带副作用的初始化（比如连 Redis），因为init()无法读取-test.*参数，也没法优雅报错
多个测试文件共存时的冲突风险
一个包下只能有一个 TestMain。如果两个 _test.go 文件都定义了它，go test 会直接报错 multiple definitions of TestMain。
- 哪怕两个文件测试不同功能，也必须合并到同一个
TestMain中统一管理生命周期 - 如果某个测试文件临时需要独立 setup/teardown，优先考虑在
TestXxx内部手动调用，而不是另起TestMain - 跨包共享初始化？不行。
TestMain只对当前包生效，其他包的测试完全不受影响
最易被忽略的一点：你写的 TestMain 里哪怕只有一行 fmt.Println("start")，它也会强制改变整个包测试的执行流程——包括 flag 解析时机、超时控制、并发调度。别把它当普通日志入口用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
