Go testexit 怎么处理清理回调

遇到“Go testexit 怎么处理清理回调”时，先记住一个边界：os.Exit 是进程级终止，调用后不会执行当前 goroutine 的 defer，也不会执行 t.Cleanup；t.Fatal、FailNow 走的是 runtime.Goexit 路径，测试框架仍有机会按生命周期运行清理回调。要验证退出码，最稳妥的做法是把真实退出放进子进程，而不是试图在当前测试进程里“拦截”它。

先分清 os.Exit 与测试框架的两条退出路径

t.Cleanup 的语义是“当前测试及其子测试结束时调用”，注册顺序还是后进先出。它适合清理临时目录、还原环境变量和关闭测试资源，但它不是操作系统的退出钩子。

因此下面几种结束方式不能混为一谈：

Go 工具链还专门覆盖了测试函数调用 os.Exit(0) 的场景：过早的零退出码不能让测试直接被判定为成功。这个保护属于测试基础设施内部行为，业务代码不应依赖内部包或链接名来实现自己的清理。

清理资源时，把责任交给测试生命周期

资源创建函数可以直接注册清理动作，调用方只拿资源，不必记住另一个 teardown 函数。清理函数可以在测试失败、子测试结束等正常测试框架路径上执行：

package worker_test

import (
    "os"
    "testing"
)

func TestTemporaryConfig(t *testing.T) {
    dir := t.TempDir() // 中文说明：测试框架会在测试及子测试完成后删除目录
    old, had := os.LookupEnv("APP_CONFIG_DIR")
    if err := os.Setenv("APP_CONFIG_DIR", dir); err != nil {
        t.Fatal(err)
    }
    t.Cleanup(func() {
        // 中文说明：还原进程环境，避免影响同一测试二进制中的后续测试
        if had {
            _ = os.Setenv("APP_CONFIG_DIR", old)
        } else {
            _ = os.Unsetenv("APP_CONFIG_DIR")
        }
    })
}

这里的关键不是“回调一定会在任何退出前执行”，而是把回调绑定到 testing.T 的生命周期。若被测代码内部直接调用 os.Exit，当前测试进程没有机会执行上面的还原逻辑；这也是测试中不建议让库函数直接退出进程的原因。

单元测试优先替换退出动作

如果退出只是命令行层的策略，可以把业务层改为返回错误，再由 main 统一决定退出码。暂时不能重构时，至少把退出函数作为依赖注入：

package command

import "os"

var exitProcess = os.Exit

func Run(exit func(int)) error {
    // 中文说明：业务层只表达失败原因，不直接结束测试进程
    if err := loadConfig(); err != nil {
        exit(2)
        return err
    }
    return nil
}

func Main() {
    // 中文说明：生产入口传入真实退出函数，测试可以传入记录器
    _ = Run(exitProcess)
}

func loadConfig() error { return nil }

测试时传入一个只记录参数的函数，就能检查退出码、调用次数和错误返回，同时让 t.Cleanup 留在当前进程里正常工作。不要在多个并行测试之间修改全局 exitProcess；更好的做法是把它放到结构体字段或构造函数参数中。

必须验证真实退出码时，使用隔离子进程

若目标就是确认程序确实以某个状态码结束，子进程测试才是正确边界。父测试负责启动和读取结果，子测试只负责触发退出；这样不会杀掉承载其他测试的父进程。

func TestExitCode(t *testing.T) {
    if os.Getenv("GO_WANT_HELPER_PROCESS") == "1" {
        // 中文说明：子进程只执行被测退出分支，避免父测试被 os.Exit 终止
        os.Exit(2)
    }

    cmd := exec.Command(os.Args[0], "-test.run=^TestExitCode$")
    cmd.Env = append(os.Environ(), "GO_WANT_HELPER_PROCESS=1")
    err := cmd.Run()
    var exitErr *exec.ExitError
    if !errors.As(err, &exitErr) {
        t.Fatalf("期望子进程退出，实际错误为 %v", err)
    }
    if exitErr.ExitCode() != 2 {
        t.Fatalf("期望退出码 2，实际为 %d", exitErr.ExitCode())
    }
}

这个示例需要导入 errors、os、os/exec 和 testing。子进程里的 os.Exit 同样不会执行清理回调，所以不要把父进程资源交给子进程清理；父进程在 cmd.Run 返回后再做自己的回收。

TestMain 只在最后一步调用 os.Exit

自定义 TestMain 时，正确的职责是让 m.Run() 完成测试，并把返回码交给进程出口。若在准备阶段直接 os.Exit，测试清理和失败结果都会被跳过；若忘记使用 m.Run() 的返回值，也可能把失败隐藏成成功。

func TestMain(m *testing.M) {
    // 中文说明：先运行全部测试，退出码只在测试框架收尾后交给进程
    code := m.Run()
    os.Exit(code)
}

实际项目可以把配置加载失败改为返回错误，让 TestMain 或 main 在最外层统一退出。这样“清理资源”和“报告退出码”各自只有一个责任，排查 testexit 类问题会简单很多。

相关问题

t.Cleanup 和 defer 应该怎么选？

只服务当前函数的局部资源可用 defer；需要覆盖测试失败、子测试和测试辅助函数创建的资源时，优先用 t.Cleanup。两者都无法抵抗 os.Exit。

t.Fatal 为什么能触发清理？

t.Fatal 会先记录失败，再通过测试框架控制当前 goroutine 的结束，框架仍能执行已注册的清理回调；它和直接调用 os.Exit 不是同一条路径。

能不能在测试里 monkey patch os.Exit？

不建议把运行时打补丁当常规方案。优先注入退出依赖；只有必须确认操作系统级退出行为时，才使用隔离子进程。