os.Setenv后未配对Unsetenv是测试污染主因，因os.Environ()为进程级全局状态，所有测试共享同一快照，导致TestA设置的环境变量残留影响TestB等后续测试。
os.Setenv 后没配对 Unsetenv 是测试污染的主因
Go 的 os.Environ() 是进程级全局状态，所有测试共享同一份环境变量快照。你在 TestA 里调用 os.Setenv("API_URL", "http://test") 却没还原，TestB 运行时读到的 os.Getenv("API_URL") 就是这个值——哪怕它本不该存在。
典型现象：单个测试跑都通过，全量 go test 却随机失败；CI 上偶发挂掉，本地复现困难；go test -run TestX 和 go test -run TestY 都过，但合起来就崩。
- 绝对不要在
init()或TestMain里直接设环境变量 - 每个测试若需修改，必须显式配对
os.Setenv+os.Unsetenv - 优先用
defer os.Unsetenv("KEY")，确保 panic 时也能还原 - 更稳妥的做法：把
os.Getenv调用从函数体内移出来，作为参数传入（见下节）
把 os.Getenv 拉出业务逻辑，改成显式参数
直接在函数里写 os.Getenv("DB_TIMEOUT")，等于把环境依赖硬编码进执行路径。测试时你既不能模拟超时值，也无法验证空字符串或非法数字的处理逻辑，更没法控制并发下多个测试同时改写该变量。
这不是“加 mock”的问题，是设计层面的耦合。解法是让依赖可见、可控：
立即学习“go语言免费学习笔记（深入）”；
- 把环境变量读取提前到入口层（如
main()或测试 setup），转成结构体字段或函数参数 - 例如：
NewService(timeout time.Duration)而不是NewService()内部自己读os.Getenv - 测试时直接传
time.Second或0，无需碰环境变量 - 如果必须保留配置加载逻辑，封装成可注入的函数类型，比如
func() string，测试时替换为固定返回值
用 t.Setenv 替代 os.Setenv（Go 1.17+）
Go 1.17 引入了 t.Setenv，它会自动在测试结束时还原环境变量，比手写 defer os.Unsetenv 更可靠，且兼容 t.Parallel()。
但它只在当前测试作用域生效，不影响其他测试，也不影响 os.Environ() 的全局快照——这是它的设计意图，也是它安全的原因。
- 用法简单：
t.Setenv("LOG_LEVEL", "debug") - 不支持还原旧值（比如原值是
"info"，设成"debug"后恢复的是空，不是"info"） - 若需精确还原旧值（比如测试要求“原值非空时才覆盖”），仍得用
old := os.Getenv("X"); defer os.Setenv("X", old) - 注意：旧版 Go 不支持，CI 环境需确认 Go 版本
别忽略 .env 文件加载时机和路径
godotenv.Load() 不是魔法，它只是把文件内容注入进程环境变量。如果在 init() 里调用，加载顺序不可控；如果在 main() 之后才调，业务代码已经用 os.Getenv 读过空值了。
更麻烦的是，godotenv.Load() 默认读当前工作目录（pwd），不是源码目录。CI 脚本常 cd 到构建目录再运行 go test，结果 .env 根本没被加载。
- 必须放在
main()最开头，且在任何业务逻辑之前 - 路径要显式指定：
godotenv.Load(filepath.Join(rootDir, ".env"))，其中rootDir可用runtime.Caller推导 - 测试中不要依赖
.env—— 它本质还是改os.Environ()，污染风险同上；测试应走参数注入路径
os.Getenv，你就得时刻提防它在某个角落悄悄改写全局状态。真正干净的解法，是让所有外部输入都成为函数签名的一部分——哪怕多写两行参数，也比花半天排查偶发失败强。 
