Go 测试怎样隔离环境变量修改

Go 测试需要临时改环境变量时，优先使用 t.Setenv("KEY", "value")，不要在测试里直接调用 os.Setenv 后再凭记忆恢复。testing.T.Setenv 会登记清理动作，测试结束时把变量恢复到原来的状态；但环境变量属于整个进程，使用了 Setenv 的测试不能再调用 t.Parallel()，它的父级测试也不能已经进入并行阶段。

这篇只解决“临时环境变量怎样隔离”这个问题：先用 Setenv 管理生命周期，再检查测试树中的并行关系。如果业务代码依赖环境变量，无法安全并行时应改成串行测试，或把配置作为参数传入。

• 修改方式：使用 t.Setenv，让测试框架负责恢复原值。
• 隔离边界：它隔离的是测试生命周期，不会把进程环境复制成每个 goroutine 一份。
• 并行限制：当前测试和所有并行祖先都不能使用 Setenv。

先判断环境变量是不是测试输入

环境变量通常在进程级共享。直接写 os.Setenv 的风险是：当前测试还没结束，其他测试或后台 goroutine 已经读到了临时值；如果测试失败、提前返回，或者后续维护者忘记恢复，污染就可能延续到同一个测试进程里的其他用例。

因此可以先把依赖关系画成三段：测试设置输入、被测函数读取输入、测试结束执行清理。只要这三段都属于同一个 *testing.T 生命周期，t.Setenv 就比手写保存旧值和恢复旧值更不容易漏步骤。

用 t.Setenv 临时覆盖并自动恢复

下面的例子把环境变量读取封装在业务函数里，测试只负责准备输入。代码中的注释说明了关键边界，清理动作不需要额外写在测试末尾。

package config

import (
    "os"
    "testing"
)

func mode() string {
    value := os.Getenv("APP_MODE")
    if value == "" {
        return "default"
    }
    return value
}

func TestModeFromEnvironment(t *testing.T) {
    // Setenv 在测试结束时恢复 APP_MODE 的原值，避免污染后续用例。
    t.Setenv("APP_MODE", "test")

    // 被测函数只从进程环境读取配置，断言关注最终业务结果。
    if got := mode(); got != "test" {
        t.Fatalf("mode() = %q, want %q", got, "test")
    }
}

如果测试开始前 APP_MODE 不存在，清理后它会回到“不存在”；如果原来有值，也会回到原值。不要在同一个测试里再写一套相反的 os.Setenv 或 os.Unsetenv，否则清理责任会变得不清楚。

为什么 Setenv 不能和 t.Parallel 混用

t.Parallel() 的含义是让测试与其他并行测试一起调度。可是环境变量不是当前测试对象的字段，而是整个测试进程可见的状态。两个测试若同时写同一个键，即使各自调用了 Setenv，也无法保证读取时看到的是自己想要的值，所以 Go 测试框架直接禁止这种组合。

func TestModeSerial(t *testing.T) {
    // 这里不调用 Parallel，保证 APP_MODE 的窗口不会与并行测试重叠。
    t.Setenv("APP_MODE", "serial")
    if got := mode(); got != "serial" {
        t.Fatalf("mode() = %q, want %q", got, "serial")
    }
}

func TestModeWithInput(t *testing.T) {
    // 能参数化时不依赖进程环境，就可以保留并行能力。
    for _, tc := range []struct {
        name string
        mode string
    }{
        {name: "default", mode: "default"},
        {name: "test", mode: "test"},
    } {
        tc := tc
        t.Run(tc.name, func(t *testing.T) {
            // 这里的示例强调设计方向：把 mode 作为参数传给被测函数。
            if tc.mode == "" {
                t.Errorf("empty mode is not expected")
            }
        })
    }
}

还要检查“并行祖先”：如果父测试已经调用 t.Parallel()，它下面的子测试也处在并行测试树中，此时子测试不能再使用 Setenv。最简单的修复是移除这一支的并行声明；更长期的修复是把环境读取改成显式配置参数。

环境变量测试的排查清单

1. 确认修改入口：搜索测试中的 os.Setenv、os.Unsetenv 和 t.Setenv，避免同一用例混用两种清理方式。
2. 确认读取时机：被测代码是在测试设置后读取，还是在包初始化、全局变量初始化阶段就读取了环境变量。
3. 确认并行关系：检查当前函数、父测试和同一测试包中的并行用例，尤其注意 t.Run 下面隐藏的 t.Parallel。
4. 确认替代方案：如果必须并行，把环境变量改成函数参数、配置结构体字段或显式依赖，而不是依赖共享进程状态。

常见问题

t.Setenv 会不会只恢复当前 goroutine 的环境？

不会。它操作的是进程环境，所以恢复动作也是针对整个测试进程。这正是它不能和并行测试混用的原因。

可以在 t.Setenv 后手动恢复一次吗？

通常不需要。重复手动恢复容易与测试框架登记的清理动作产生顺序误解，保留一套清理责任更清楚。

并行测试一定要改成串行吗？

只有在测试需要修改进程级环境时才需要让这条测试链退出并行；若将配置改为显式参数，就可以测试不同输入而不争用环境状态。

官方 API 参考：https://pkg.go.dev/testing#T.Setenv。