Go测试中读取配置文件应通过TestMain统一初始化，优先用环境变量传路径避免硬编码，配置文件放根目录并忽略敏感内容，禁止init加载，须校验os.ReadFile错误，动态修改需函数封装防污染。
Go测试中读取配置文件的常见方式
Go测试本身不提供内置的配置加载机制，必须手动在 TestMain 或测试函数中解析配置。最稳妥的做法是把配置文件路径通过命令行参数或环境变量传入，避免硬编码路径导致 CI 失败或本地测试路径不一致。
- 推荐放在项目根目录下，如
test-config.json或config.test.yaml，并在.gitignore中排除敏感配置 - 不要在
init()中加载配置——测试包可能被并行执行，init无序且不可控 - 若用
os.ReadFile读取，务必检查错误：空文件、权限拒绝、路径拼错都会让测试静默失败
用 TestMain 统一初始化测试配置
TestMain 是唯一能拦截所有测试执行前/后的入口，适合一次性读取、校验并注入全局配置。注意它必须调用 m.Run()，否则所有测试不执行。
func TestMain(m *testing.M) {
cfg, err := loadTestConfig("test-config.json")
if err != nil {
fmt.Fprintf(os.Stderr, "failed to load test config: %v\n", err)
os.Exit(1)
}
// 注入到包级变量或使用闭包传递（更安全）
testConfig = cfg
os.Exit(m.Run())
}
- 配置结构体建议用指针传递，避免拷贝大对象
- 不要在
TestMain中启动 HTTP server 或数据库连接——这些应由具体测试按需 setUp/tearDown - 若配置含密码等敏感字段，确保测试配置文件不提交到 Git，CI 中通过 secret 注入环境变量替代
环境变量 vs 配置文件：什么情况下该选哪个
环境变量适合简单开关或连接串（如 TEST_DB_URL），配置文件更适合嵌套结构（如重试策略、mock 行为开关）。混合使用最常见：用环境变量控制「用哪份配置」，再读对应文件。
- CI 场景优先用环境变量：
go test -v ./... -args -env=staging，然后在代码里根据os.Args或os.Getenv("ENV")加载config.staging.yaml - 本地开发可默认读
config.local.yaml，但必须允许被TEST_CONFIG_PATH环境变量覆盖 -
os.Setenv在测试中修改环境变量仅对当前进程有效，但子进程（如 exec.Command）会继承——这点常被忽略导致 mock 失效
测试中动态修改配置的陷阱
有些测试需要临时覆盖某个配置项（比如把超时从 30s 改成 100ms），直接改全局变量会导致测试间污染。Go 没有类似 Jest 的 jest.mock 隔离机制，必须手动处理。
- 用函数式封装配置访问，如
GetTimeout() time.Duration，测试中用闭包替换实现 - 避免直接导出配置 struct 字段；导出 getter 方法，内部可切换实现
- 并发测试下，若用
sync.Map存临时配置，记得每个测试 clean 自己的 key，否则后续测试可能读到残留值
TestMain 就 panic 错误，而不是等到某个测试里连不上 DB 才报错。路径、格式、字段缺失这三类问题，90% 都能在启动阶段拦截。 
