测试中os.Setenv未生效，因os.Getenv等在init()或包加载阶段已读取环境变量快照，后续Setenv无法影响已缓存值；应推迟读取、传参替代或用viper.Set/koanf.MockProvider显式注入。
测试里改 os.Setenv 为什么没生效？
因为 Go 的 os.Environ() 和 os.Getenv() 在测试中读取的是进程启动时的快照，而 os.Setenv 只影响后续调用——但很多库（比如 viper、flag 初始化逻辑）在 init() 或包加载阶段就已读完环境变量，此时再 Setenv 已经晚了。
- 真实场景：写了一个
LoadConfig()函数，在init()里调用了os.Getenv("DB_URL")，测试中先os.Setenv("DB_URL", "test://")再调用函数，结果还是空字符串 - 根本原因：环境变量读取发生在函数执行前，甚至可能在测试函数开始前就完成了
- 安全做法：把环境读取逻辑推迟到函数内部，或显式传入
map[string]string模拟环境
用 os.Unsetenv + defer os.Setenv 不够可靠
单纯靠 os.Unsetenv 清理旧值、再 os.Setenv 注入新值，容易被并发测试干扰，也挡不住其他测试用例提前读取了环境变量。
- Go 测试默认并发执行（
go test -race下尤其明显），多个测试同时调用os.Setenv会互相覆盖 -
os.Unsetenv("PATH")这类操作可能导致子进程启动失败（比如调用exec.Command("sh")时找不到解释器） - 更稳妥的方式是封装一个「干净环境」执行器：
func withEnv(env map[string]string, f func())，用os/exec.Cmd.Env构造隔离上下文，或直接传参替代全局读取
Mock 环境变量的三种实用路径
不依赖全局状态，才是可测性的起点。优先级从高到低：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 重构代码：把
os.Getenv调用提到函数参数里，例如func NewClient(url string) *Client，测试时直接传"test://" - 接口抽象：定义
type EnvReader interface { Get(key string) string }，生产用osEnvReader，测试用staticEnvReader，避免硬编码os. - 临时替换（仅限无法改源码时）：用
gomonkey打桩os.Getenv，但要注意它不能 patchinit()阶段的调用，且和-race不兼容
使用 viper 或 koanf 时怎么注入测试环境？
这些配置库默认会自动读取环境变量，但它们都支持显式设置来源（source），绕过自动扫描是最干净的做法。
立即学习“go语言免费学习笔记（深入）”；
-
viper：调用viper.AutomaticEnv()之前先viper.Reset()，然后用viper.Set("db.url", "test://")直接设值，跳过环境读取环节 -
koanf：构造时传入koanf.WithProvider(&mockProvider{m: map[string]interface{}{"db.url": "test://"}}，完全隔离外部输入 - 注意：如果开启了
viper.BindEnv("db.url", "DB_URL")，测试中仍要确保DB_URL未被意外设置，否则绑定逻辑会覆盖Set的值
go test 都像在猜当前机器上谁动过 $HOME。 
