Go测试中环境变量、外部服务、时间相关逻辑易失效，根本原因是被测代码未预留可替换入口，应通过依赖注入、接口抽象和延迟读取等方式提升可测性。
Go 测试环境变量设置不生效？检查 os.Setenv 调用时机
单元测试中用 os.Setenv 设置环境变量，但后续代码读取不到——大概率是因为调用发生在 init() 函数或包级变量初始化阶段之后。Go 的包初始化顺序是：常量 → 变量 → init()，而测试文件的 init() 或 TestXxx 函数执行时，被测包可能早已完成初始化并缓存了旧的环境值。
- 把
os.Setenv放在每个测试函数开头（func TestXxx(t *testing.T)内），并在末尾用os.Unsetenv清理 - 若被测逻辑在
init()中读取环境变量，无法通过测试覆盖——应重构为延迟读取（例如封装成函数或使用依赖注入） - 避免在
TestMain中全局设置，除非你明确控制所有测试的执行顺序且确保无并发
数据库连接等外部依赖启动失败？用 testify/suite 或 setup/teardown 隔离
测试依赖真实 MySQL 或 Redis 时，常见错误是多个测试共用同一连接、未清理测试数据、或端口被占导致启动失败。直接在 TestXxx 里启停服务既慢又不可靠。
- 用
testify/suite提供的SetupTest和TeardownTest方法，每次测试前创建独立 DB 实例（如用testcontainers-go启动临时容器） - 若必须复用连接，确保连接对象是测试函数局部变量，而非包级变量；否则并发测试会相互干扰
- 对 SQLite 等嵌入式 DB，用
:memory:模式或带随机后缀的临时文件路径（如fmt.Sprintf("test_%d.db", time.Now().UnixNano())）
HTTP 客户端超时或证书校验失败？用 httptest.Server 替代真实请求
测试调用外部 API 时，硬编码 http.DefaultClient 会导致测试不稳定、慢、且无法断言请求细节。更糟的是，某些 TLS 配置（如自签名证书）会让 http.Client 直接 panic。
- 用
httptest.NewServer启动一个内存 HTTP 服务，返回预设响应，再将被测客户端的BaseURL指向它 - 若需模拟重试、超时、重定向等行为，可包装
http.RoundTripper，在RoundTrip方法中按需返回错误或伪造响应 - 禁用 TLS 校验仅用于开发调试，切勿出现在测试代码中——正确做法是用
httptest.NewUnstartedServer+ 自签名证书生成器（如crypto/tls）构造可信上下文
Mock 时间相关逻辑总出错？别用 time.Now()，改用接口抽象
直接调用 time.Now() 或 time.Sleep 的代码极难测试：时间不可控、测试耗时、结果非确定。常见错误是试图用 monkey.Patch 劫持标准库函数——这在 Go 1.18+ 会因内联优化失效，且破坏类型安全。
立即学习“go语言免费学习笔记（深入）”；
- 定义
type Clock interface { Now() time.Time }，默认实现为realClock{}，测试时传入fixedClock{t: testTime} - 对需要等待的逻辑（如重试），将
time.Sleep替换为接受func(time.Duration)的参数，测试时传入空函数 - 避免在结构体字段中直接存
time.Time，改用time.Time的封装类型（如type Timestamp time.Time），并在其方法中依赖注入Clock
type Service struct {
clock Clock
}
func (s *Service) DoSomething() {
t := s.clock.Now() // 可 mock
// ...
}
环境变量、外部服务、时间——这三个点最容易让 Go 单元测试从“快速可靠”变成“随机失败”。真正关键的不是怎么 mock，而是被测代码是否预留了可替换的入口。如果发现某个测试必须用反射或 patch 才能跑通，那问题通常不在测试，而在设计。
