testing.t.setenv 是 go 1.17+ 的测试专用环境变量设置方法，仅对当前测试及其子测试生效，不污染全局环境，且自动还原；低于 go 1.17 会 panic，需检查版本；它不影响提前缓存的环境变量值，也不等同于 os.setenv。
testing.T.Setenv 是 Go 1.17+ 才有的功能
它只在测试运行时生效，且仅对当前 testing.T 及其子测试有效。低于 Go 1.17 的版本调用会 panic，错误信息是 undefined: t.Setenv。如果你在 CI 或本地跑测试时报这个错，先检查 go version —— 不是写法问题，是版本不够。
Setenv 修改的是 os.Environ() 看到的环境变量副本
它不会污染全局进程环境，也不影响其他测试函数。但要注意：如果被测代码在测试开始前就缓存了 os.Getenv("FOO") 的结果（比如包级变量初始化时读取），t.Setenv("FOO", "bar") 就不起作用 —— 因为值早就存进变量里了。
- ✅ 正确用法：被测函数每次调用都重新读取
os.Getenv - ❌ 常见坑：在
init()或包变量声明中提前读取环境变量 - ⚠️ 注意：子测试（
t.Run）会继承父测试设置的环境变量，但无法修改父测试的环境变量副本
Setenv 和 os.Setenv 的关键区别
t.Setenv 是测试专用的隔离机制；os.Setenv 会真实修改进程环境，且不自动还原，容易导致测试间干扰。即使你手动配对 os.Unsetenv，也得确保 defer 执行顺序正确，否则 panic 或漏清理。
- ✅ 推荐：优先用
t.Setenv("KEY", "val")，无需手动清理 - ❌ 避免：在测试里用
os.Setenv+defer os.Unsetenv，尤其当测试 panic 时 defer 可能不执行 - ? 补充：如果必须用
os.Setenv（比如测试跨 goroutine 的环境读取），记得在测试末尾显式os.Unsetenv，并验证是否真被清除了
实际测试中怎么写才可靠
直接在测试函数开头调用 t.Setenv 即可，它比 t.Cleanup 更早生效，且保证在测试结束时自动还原。不需要额外 setup/teardown 逻辑。
func TestMyFuncWithEnv(t *testing.T) {
t.Setenv("API_BASE_URL", "http://test.local")
t.Setenv("DEBUG", "true")
result := MyFunc() // 内部调用 os.Getenv("API_BASE_URL")
if result != "http://test.local" {
t.Fatal("expected API_BASE_URL to be used")
}
}
如果测试中启动了子进程（如 exec.Command），t.Setenv 同样生效 —— 它会注入到子进程的 Cmd.Env 中（Go 1.20+ 自动处理，旧版需手动传 cmd.Env = append(os.Environ(), ...)）。
最常被忽略的一点：Setenv 只影响当前测试 goroutine，不穿透到其他并发运行的测试；但如果你在测试里启了新 goroutine 并在里面读环境变量，只要没显式传递，它看到的仍是修改后的值 —— 因为 os.Getenv 读的是当前进程的环境块，而 t.Setenv 修改的就是那个块的测试副本。
