t.Setenv能替代os.Setenv，因其为当前测试实例安全注入环境变量，测试结束自动还原，避免并发panic和脏值干扰，且零系统调用开销。
t.Setenv 是最直接、最安全的方式，但只在测试函数内生效，且要求被测代码不缓存环境变量。
为什么 t.Setenv 能替代 os.Setenv
Go 1.17+ 的 t.Setenv 为当前 *testing.T 实例注入环境变量，测试结束自动还原，无需 defer os.Unsetenv。它天然支持并发测试（t.Parallel()），不会因漏 cleanup 或 panic 导致后续测试读到脏值。
常见错误现象：os.Setenv("DEBUG", "true") 后子测试仍看到空值，或多个测试互相覆盖；os.Unsetenv("PATH") 导致 exec.Command 启动失败。
-
t.Setenv修改的是测试框架内部维护的t.env字段，不触碰进程全局环境，零系统调用开销 - 对子 goroutine 有效——只要它们在测试函数生命周期内运行
- 不适用于
init()阶段已读取环境变量的代码（比如包级变量初始化）
t.Setenv 对子进程无效，必须显式传入 cmd.Env
当你测试的函数内部调用了 exec.Command，t.Setenv 设置的变量不会自动出现在子进程中。子进程启动时继承的是父进程当时的 os.Environ() 快照，而 t.Setenv 并不修改它。
立即学习“go语言免费学习笔记（深入）”；
典型错误现象：测试里 t.Setenv("API_URL", "https://test.api")，但 exec.Command("sh", "-c", "echo $API_URL") 输出空字符串。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 正确做法是手动构造
cmd.Env：cmd.Env = append(os.Environ(), "API_URL=https://test.api") - 如果被测函数封装了
exec.Command，需重构它接受可选的env []string参数 - 注意：
cmd.Env会完全替换子进程环境，所以一般要基于os.Environ()追加，而非直接赋值
被测代码缓存了 os.Getenv 结果，t.Setenv 就失效
很多老代码把 os.Getenv("PORT") 结果赋给包级变量，在 init() 里读一次就不再更新。这种写法让 t.Setenv 完全无效——因为测试时变量早已初始化完毕。
快速验证是否被缓存：在测试中先 t.Setenv("PORT", "8080") 调一次被测逻辑，再 t.Setenv("PORT", "9000") 调第二次；如果两次都返回 8080，说明被缓存了。
- 正确做法：把环境变量读取推迟到函数执行时，或封装成可注入选项（如
NewServer(opt ServerOption)） - 临时补救（不推荐）：用
unsafe强制重置包级变量，或改用构建标签 + fake 环境变量接口 - 某些配置库（如
godotenv或自定义加载器）调用os.Environ()获取快照后就固定了，后续t.Setenv不会反映其中
测试中跳过环境依赖项要用 t.Skip，不是 t.Fatal
当测试需要外部服务（如数据库、API）、特定 OS 或环境变量才可运行时，该跳过而不是失败。用 t.Skip() 表示“当前环境不适用”，不计入失败数，不影响 CI/CD 流水线结果。
典型使用场景：if os.Getenv("INTEGRATION_TEST") == "" { t.Skip("skipping integration test") }。
- 避免在
TestMain中用os.Setenv全局设置——它会让所有测试共享同一份环境，彻底失去隔离性 - 不要用
t.Fatal或t.Error报告环境缺失，那会让 CI 认为是代码缺陷 - 消息要具体，比如
t.Skip("requires DB_URL to be set for integration test")，方便排查
真正容易被忽略的是：环境变量读取时机和作用域边界。t.Setenv 生效的前提，是你控制得了被测代码何时读、怎么读——否则再干净的沙箱也进不去。
