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+ 会因内联优化失效，且破坏类型安全。

• 定义 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 才能跑通，那问题通常不在测试，而在设计。