Go 并行测试里为什么不能随意修改环境变量

并行测试里不能随意调用 t.Setenv，根本原因不是清理做得不够，而是环境变量属于整个测试进程。testing.T.Setenv 会修改进程环境，并在测试结束时恢复原值；如果测试已经调用 t.Parallel，或它有并行祖先，另一个测试可能在同一时间读到这次修改，Go 因此明确禁止这种组合。

为什么 Setenv 会和 t.Parallel 直接冲突

t.Parallel() 表示当前测试可以和其他并行测试同时运行。此时多个测试通常仍在同一个测试进程中，而 os.Getenv 读取的是这个进程的环境。假设测试甲把 APP_MODE 改成 staging，测试乙恰好读取同一个键，乙看到的值就取决于两者的时机，而不是自己的测试数据。

这也是为什么下面的写法不该靠“多跑几次没问题”来判断：

func TestConfig(t *testing.T) {
    t.Parallel()
    // Setenv 改的是整个测试进程，不是当前测试的局部变量。
    t.Setenv("APP_MODE", "test")
    if got := os.Getenv("APP_MODE"); got != "test" {
        t.Fatalf("APP_MODE = %q", got)
    }
}

实际执行时，Go 测试框架会直接拒绝这种调用组合。即便某个版本或某条路径没有立刻报错，其他并行测试也可能读到临时值，所以它仍然是错误的隔离模型。

Setenv 的 Cleanup 能恢复什么，不能恢复什么

Setenv(key, value) 做两件事：先设置键值，再登记清理动作，在测试结束后恢复原来的存在状态和值。它解决了“测试结束后不要污染后续测试”的问题，却没有解决“测试运行期间谁能看到这个值”的问题。

所以，看到“Setenv 最后会自动还原”时，应该把它理解为生命周期保证，而不是并发保证。尤其是一个测试启动了后台 goroutine，而业务代码又在后台读取环境变量时，清理发生前仍可能存在未定义的观察关系。

按测试目标选择隔离方案

如果测试只是想让配置读取结果可控，最稳妥的做法是把环境读取包在一个小接口里，测试直接注入值。这样每个并行子测试都拥有自己的输入，不需要触碰进程环境：

type EnvLookup func(string) string

func endpoint(get EnvLookup) string {
    // 业务函数依赖读取能力，而不是依赖全局环境本身。
    if value := get("API_ENDPOINT"); value != "" {
        return value
    }
    return "https://default.invalid"
}

func TestEndpoint(t *testing.T) {
    t.Parallel()
    // 每个并行测试注入独立值，不修改 os.Environ。
    got := endpoint(func(string) string { return "https://stub.invalid" })
    if got != "https://stub.invalid" {
        t.Fatalf("endpoint = %q", got)
    }
}

如果被测对象必须通过 os.Getenv 读取，并且你要验证真实的进程环境语义，就把这项测试放在串行边界，或启动独立子进程。子进程的 Cmd.Env 是该进程的环境列表，不会和当前测试进程共用同一份修改：

cmd := exec.Command(os.Args[0], "-test.run=TestHelperProcess")
// 只给子进程注入环境，避免改动当前测试进程。
cmd.Env = append(os.Environ(), "APP_MODE=child")
if err := cmd.Run(); err != nil {
    t.Fatalf("helper process: %v", err)
}

选择可以记成一句话：测业务逻辑就注入配置，测环境变量本身就隔离进程，只有确实不需要并行时才在串行测试中使用 t.Setenv。

用检查清单避免偶发失败

提交测试前，可以按下面的顺序检查：

1. 搜索 t.Parallel、t.Setenv、os.Setenv 和 os.Getenv，确认它们是否出现在同一条测试路径。
2. 检查 t.Run 的父子关系：当前测试没有直接调用 t.Parallel，不代表它没有并行祖先。
3. 后台 goroutine 是否还会读取环境？如果会，优先改成创建时传入配置，避免依赖动态全局值。
4. 需要覆盖多个环境组合时，用表驱动测试加显式参数；需要覆盖真实环境时，用 exec.Cmd.Env。
5. 保留 t.Setenv 的场景应当是串行、边界清楚且没有并行祖先，并让清理责任留给 testing 包。

常见问题

只在父测试里调用 Setenv，子测试都并行，安全吗？

父测试本身必须保持串行，且要确认这组子测试共享同一个固定值；如果测试还会与其他环境敏感测试交错，改用显式配置或独立进程更清楚。

把 Setenv 放到 t.Parallel 前面可以吗？

不要把调用顺序当成隔离方案。测试一旦进入并行模型，进程环境仍然是共享状态；应改成串行边界或注入配置。

os.Setenv 手动 defer 恢复是否比 Setenv 更灵活？

它只能改变清理写法，不能改变进程级作用范围。并行测试仍不应使用它修改共享环境。

判断这类问题的关键不是“值有没有恢复”，而是“值在测试运行期间由谁共享”。把配置变成参数，或把真实环境推到子进程，通常比围绕全局变量安排执行时机更可靠。