go测试中os.setenv不还原会导致环境变量污染，因os.environ()是进程级全局状态，所有测试共享；必须配对setenv/unsetenv并还原原值，或改用依赖注入避免副作用。
Go test 里改 os.Setenv 后不还原，为什么测试会互相污染？
因为 Go 的 os.Environ() 是进程级全局状态，os.Setenv 和 os.Unsetenv 直接修改运行时环境，同一进程内所有测试共享。如果你在某个 TestXxx 里调用 os.Setenv("DEBUG", "1") 却没恢复，后续测试读到的 os.Getenv("DEBUG") 就是 "1"——哪怕它本该是空。
常见错误现象：go test -run TestA 通过，go test -run TestB 也通过，但 go test 全量跑就失败；或者 CI 上偶发失败，本地复现困难。
- 别在
TestMain或init函数里直接设环境变量 - 每个测试若需修改环境，必须配对使用
os.Setenv+os.Unsetenv（或还原旧值） - 优先用
defer保证还原执行，哪怕测试 panic
用 testify/suite 做环境隔离时，SetupTest 和 TeardownTest 怎么写才安全？
不是所有测试框架都自动帮你快照环境。用 testify/suite 时，SetupTest 是起点，TeardownTest 是终点，但它们本身不感知环境变化——你得自己记下原始值。
关键点在于：不能只 os.Unsetenv，因为原值可能本来就是某个字符串（比如 "production"），直接删掉就丢数据了。
立即学习“go语言免费学习笔记（深入）”；
- 在
SetupTest里用os.Getenv读取要干预的变量，存为结构体字段（如s.oldDebug = os.Getenv("DEBUG")） - 在
SetupTest中调用os.Setenv设置测试所需值 - 在
TeardownTest中先os.Unsetenv，再用if s.oldDebug != "" { os.Setenv("DEBUG", s.oldDebug) }还原 - 避免在
TeardownTest里依赖os.Getenv读当前值来判断是否还原——它可能已被其他测试篡改
os.Setenv 在子进程场景下失效，是因为父进程环境没传过去？
不是失效，是根本没继承。Go 启动子进程（如 exec.Command("sh", "-c", "echo $FOO")）时，默认只继承当前 os.Environ() 快照，而这个快照在 exec.Command 调用那一刻就固定了。你在之后调用 os.Setenv，不影响已创建的 *exec.Cmd 实例。
所以问题常出现在：测试里先 cmd := exec.Command(...)，再 os.Setenv("FOO", "bar")，然后 cmd.Run() —— 子进程永远看不到 FOO。
- 必须在
exec.Command之前设好环境，或显式用cmd.Env覆盖 - 更稳妥的做法：
cmd := exec.Command("sh", "-c", "echo $FOO"); cmd.Env = append(os.Environ(), "FOO=bar") - 注意
cmd.Env若全量替换，要手动补上PATH等基础变量，否则命令可能找不到
想彻底避免环境变量副作用，有没有比快照还原更轻量的办法？
有，而且更推荐：把环境变量读取逻辑抽离成可注入的函数参数，测试时直接传 mock 值，绕过 os.Getenv。
比如业务代码原本是 level := os.Getenv("LOG_LEVEL")，改成 func NewLogger(getenv func(string) string) *Logger，测试时传 func(k string) string { return "debug" }。这样既没副作用，又不用操心还原时机。
- 适合新模块或可改造的配置读取层
- 不适合第三方库硬编码调用
os.Getenv的情况（这时还是得快照+还原） - 如果项目已大量使用
os.Getenv，可用 go:linkname 黑科技临时劫持，但维护成本高，仅限调试
环境变量的“快照-还原”本质是补救措施，真正干净的解法，是让依赖变得显式、可控。这点容易被忽略，尤其当团队习惯“写完能跑就行”时。
