t.Setenv仅作用于当前测试goroutine，不影响子进程或并发测试；需显式通过cmd.Env传递环境变量给子进程，避免使用os.Setenv造成污染。
Go 1.17+ 的 t.Setenv 确实能改环境变量，但只在当前测试 goroutine 生效
它不是全局覆盖，也不会影响子进程或并发运行的其他测试用例。如果你写了个 os.Setenv 然后跑 exec.Command，那子进程看到的仍是原始环境 —— t.Setenv 对它完全无效。
适用场景很明确：函数内部直接调用 os.Getenv 做逻辑分支，且不涉及 fork/exec、不跨 goroutine 共享状态。
-
t.Setenv("DEBUG", "true")后，被测函数里os.Getenv("DEBUG")就返回"true" - 如果函数启动了新 goroutine 并在里面读环境变量，那个 goroutine 不会自动继承
t.Setenv设置 - 多个
t.Run子测试之间互不影响，每个都自带干净的环境快照
别用 os.Setenv + os.Unsetenv 手动清理，容易漏或错序
老办法要自己记哪些键改过、什么时候恢复、panic 时怎么兜底。一不小心就污染后续测试，尤其在模块级测试（TestMain）里更危险。
t.Setenv 是测试框架原生支持的“沙箱化”机制，框架会在测试结束时自动还原，包括 test panic 或 timeout 的情况。
立即学习“go语言免费学习笔记（深入）”；
- 手动
os.Setenv("PORT", "8080")后忘记os.Unsetenv("PORT")？下一个测试可能意外绑定到 8080 - 在
TestMain里用os.Setenv改环境？所有测试都会继承，彻底失去隔离性 -
t.Setenv只对当前*testing.T实例生效，天然适配t.Parallel()
遇到子进程读不到新环境？得用 cmd.Env 显式传递
比如你测试一个函数，它内部执行 exec.Command("sh", "-c", "echo $API_URL")，这时 t.Setenv("API_URL", "https://test.api") 完全没用 —— 子 shell 启动时拿到的是父进程当时的环境副本，而 t.Setenv 并不修改父进程的 os.Environ()。
正确做法是把环境变量注入到 exec.Cmd 实例里：
cmd := exec.Command("sh", "-c", "echo $API_URL")
cmd.Env = append(os.Environ(), "API_URL=https://test.api")
- 不要依赖
os.Setenv试图让子进程“自动”看到新值 - 如果被测代码封装了
exec.Command，你就得重构它，接受可选的env []string参数，测试时传入定制环境 - 注意
cmd.Env会完全替换子进程环境，所以一般要基于os.Environ()追加，而不是直接赋值
兼容旧版本 Go（testify/suite 或临时 patch os.Getenv
Go 1.16 及更早没有 t.Setenv，硬升版本不现实时，有两个务实选择：引入轻量测试辅助库，或用函数变量解耦。
- 用
testify/suite的SetupTest/TeardownTest配合os.Setenv+os.Unsetenv，至少保证单个测试生命周期内可控 - 把
os.Getenv提取成包级变量，如var getEnv = os.Getenv，测试时替换为闭包：getEnv = func(k string) string { return mockEnv[k] } - 反射 patch
os.Getenv风险高、不可靠，CI 环境可能因安全策略失败，不建议
真正麻烦的从来不是设一个变量，而是环境变量在进程树里的传播边界和时机 —— 多看一眼 exec.Cmd.Env 和 goroutine 启动点，比背 API 更管用。
