os.getenv和包级var让测试失效，因其将环境与初始化逻辑硬编码进业务路径，导致无法模拟不同配置、保障并发安全及避免跨测试状态污染；须改用显式参数注入与接口抽象实现可测性。
为什么 os.Getenv 和包级 var 会让测试环境失效
直接在函数里调用 os.Getenv("DB_URL") 或读取包级 var config Config，等于把环境和初始化逻辑硬编码进业务路径。测试时你无法：
- 模拟不同配置场景（比如空值、非法格式、超时设置）
- 保证并发安全（多个测试同时改写同一
var） - 避免跨测试残留状态（前一个测试
setenv后没 cleanup，后一个测试读到脏数据）
更麻烦的是，这类代码往往藏在工具函数里，比如 GetLogger() 或 NewHTTPClient()，表面无害，实则切断了所有测试入口。
用构造函数参数替代 init() 和全局变量
核心原则：任何外部可观测状态（环境变量、配置、客户端、logger），都必须作为输入显式传入，而不是在函数体内偷偷访问。
例如，一个依赖环境变量初始化 DB 的服务：
// ❌ 错误：隐式依赖
var db *sql.DB
func init() {
url := os.Getenv("DB_URL")
db, _ = sql.Open("mysql", url)
}
// ✅ 正确：显式依赖
type DBService struct {
db *sql.DB
}
func NewDBService(dbURL string) (*DBService, error) {
db, err := sql.Open("mysql", dbURL)
if err != nil {
return nil, err
}
return &DBService{db: db}, nil
}
这样，测试时可传入内存数据库 URL，生产环境传真实连接串，完全隔离。
接口抽象 + 依赖注入打破环境强绑定
当多个模块都要访问配置或客户端时，不能各自解析 os.Getenv，而应统一由上层注入接口实例：
- 定义
ConfigProvider接口（如GetString(key string) string），放在独立interfaces/包中 - 生产环境实现为
EnvConfig（读os.Getenv），测试环境实现为MapConfig（从 map 返回） - 各业务模块只依赖
interfaces.ConfigProvider，不感知具体来源
关键点：接口定义不能放在被注入方的包内，否则测试仍需导入生产包，又绕回循环依赖。
go mod graph 显示循环时，别急着删 require
go mod graph 报循环，90% 不是依赖写错了，而是设计层未解耦——比如 A 包导出结构体供 B 使用，B 又通过回调函数把 A 的类型传回去。
真正该做的不是删 require，而是：
- 把共用结构体或行为抽成
types或interfaces独立包 - 让 A 和 B 都 import 这个中间包，而非互相 import
- 确认
go.mod中没有因replace引入本地路径导致的假循环（replace ./local => ./local这类冗余项要清理）
循环依赖的本质不是“谁引用了谁”，而是“谁该为契约负责”。契约一旦落在具体实现包里，就注定会被拖进泥潭。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
