Go 多包测试都有 TestMain 时怎么判断执行边界

在多包项目里执行 go test ./...，最容易误判的是把所有目录想成一个测试进程。实际情况是：命令会按包构建并运行独立的测试二进制，每个包最多有自己的 TestMain。因此，internal/cache 的初始化不会自动包住 internal/http 的测试；清理也只能清理当前包创建的资源。

判断执行边界只看两层：包边界决定哪个 TestMain 被调用，m.Run 返回后到进程退出前的代码决定本包如何清理。要保留失败状态，保存 m.Run() 的返回值，并在清理完成后再退出。

go test ./... 中 TestMain 的第一条边界：包

go test ./... 不是把所有测试文件拼成一个大程序。Go 命令会为命令行匹配到的每个包准备测试二进制，再分别执行。因此，pkg/user 和 pkg/order 即使都声明了同名的 TestMain，它们也各运行一次，互相看不到对方的全局变量、临时目录和清理函数。

这也解释了两个常见现象：第一，某个包的 TestMain 日志重复出现，不代表它被同一个进程重复初始化，可能是多个包各打印了一次；第二，不能依赖包 A 的 TestMain 先创建数据，再让包 B 直接使用。跨包共享资源应放到明确的外部测试环境或由每个包自行准备。

m.Run、return 和 os.Exit 如何决定清理与失败

TestMain 在测试主 goroutine 中运行。常规做法是先准备当前包资源，再调用 m.Run，保存返回码，最后清理。下面的写法把退出动作放到清理之后：

func TestMain(m *testing.M) {
    // 只准备当前测试包需要的资源。
    cleanup := startFixture()

    // m.Run 返回本包测试的最终退出码。
    code := m.Run()

    // 无论测试成功还是失败，都先释放资源。
    cleanup()
    os.Exit(code)
}

这里的关键不是一定要调用 os.Exit，而是不能在清理之前退出。如果采用 defer cleanup()，让 TestMain 正常返回也可以：测试包装器会把 m.Run 的结果交给退出逻辑。相反，写成 defer cleanup(); os.Exit(m.Run()) 时，os.Exit 会立即终止进程，那个 defer 不会执行。

用最小实验判断多包执行边界

排查时可以在两个测试包的 TestMain 中打印不同的包名，并分别运行：

# 只运行一个包，观察它自己的 TestMain 生命周期。
go test ./pkg/user -count=1 -v

# 运行多个包；每个包都应出现自己的 TestMain 日志。
go test ./pkg/user ./pkg/order -count=1 -v

-count=1 只是为了避免成功结果命中测试缓存，便于观察本次执行；它不会把多个包合并成一个测试进程。若只看到某一个包的初始化日志，先确认命令行的包列表和构建约束，再检查日志是否写到了不同包各自的输出中。最终命令的汇总失败，只能说明至少一个包失败，不能据此推断所有包共用一个 TestMain。

常见问题

一个包能写多个 TestMain 吗？

不能把它当成多个入口使用。同一个测试二进制需要唯一的 TestMain 定义；公共初始化应集中到一个入口，再由普通辅助函数拆分职责。

TestMain 里不调用 m.Run 会怎样？

测试函数不会按预期运行，初始化函数可能看起来成功但实际没有执行测试。除非是在构造特殊测试入口，否则应调用一次 m.Run 并处理它的返回码。

包 A 的 TestMain 能给包 B 设置环境变量吗？

不要依赖这种做法。多包测试拥有独立进程和调度边界；需要的环境变量、临时文件和外部服务配置应在每个包的测试入口中显式准备。

记住“一个包一个测试二进制、一个 TestMain 包住本包、一个 m.Run 结果贯穿清理和退出”，多包测试里的重复初始化、清理缺失和失败码异常就有了清晰的排查顺序。

参考：Go testing 包文档、go test 命令文档。