集成测试前必须启动真实依赖服务，推荐用testcontainers-go启动临时容器并动态获取端口；测试末尾须用t.cleanup显式清理资源；配置需隔离构造，避免环境变量污染；超时与就绪需用waitstrategy和重试逻辑控制。
集成测试前必须启动真实依赖服务
Go 的集成测试不是跑在内存里的单元测试，它要连真实数据库、Redis 或 HTTP 服务。不启动就跑 go test，大概率看到 dial tcp 127.0.0.1:5432: connect: connection refused 这类错误。
推荐用 testcontainers-go 启动临时容器，而不是硬编码本地端口或复用开发环境——后者会让测试相互污染，CI 里还可能因端口冲突失败。
- PostgreSQL 示例：
req := testcontainers.ContainerRequest{Image: "postgres:15", Env: map[string]string{"POSTGRES_PASSWORD": "test"}}; - 启动后用
container.MappedPort(t, "5432/tcp")获取动态端口，拼接成postgres://...连接串 - 避免在
init()或包级变量里提前初始化 DB 客户端——它会抢在容器启动前执行，导致 panic
测试函数末尾必须显式清理资源
Go 测试函数退出时不会自动销毁容器、关闭数据库连接或清空 Redis。漏掉清理，轻则下次测试连错库，重则 CI 环境残留几十个僵尸容器拖慢构建。
别依赖 defer 在函数末尾清理——如果测试 panic，defer 可能不执行；更别把清理逻辑塞进 TestMain，它只在所有测试开始/结束时运行一次，无法隔离单个测试的资源。
- 每个测试函数内，用
t.Cleanup(func() { container.Terminate(t) })注册清理动作 - 对数据库，执行
db.Exec("DROP SCHEMA public CASCADE; CREATE SCHEMA public")比删表更彻底，尤其有自增 ID 或序列时 - 若用了多个容器（如 pg + redis），按启动逆序注册清理：先 redis 后 pg，避免依赖关系中断
环境变量与配置需隔离且可覆盖
测试代码读取 os.Getenv("DB_URL") 是常见陷阱——它会偷用开发机上的环境变量，导致本地能过、CI 失败；或者不同测试用同一配置，互相干扰。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
正确做法是让测试自己构造最小配置，不碰全局环境变量，也不复用生产 config 结构体。
- 在测试 setup 阶段生成临时配置：
cfg := Config{DBURL: fmt.Sprintf("postgres://%s:%s@%s:%s/%s", "test", "test", "localhost", port, "testdb")} - 禁止在
init()中调用viper.AutomaticEnv()或类似逻辑——它会在测试导入包时就加载环境变量 - 如果项目用
github.com/spf13/viper，测试中应调用viper.Reset()并手动viper.Set()所需键值，避免污染
超时与重试逻辑必须显式控制
容器启动、网络就绪、数据库迁移完成，这些都不是原子操作。直接连上去就跑 SQL，很容易遇到 pq: database "testdb" does not exist 或 connection refused。
别靠 time.Sleep(2 * time.Second) 硬等——它既不可靠（慢机器不够，快机器又浪费），也不符合 Go 的错误处理习惯。
- 用
testcontainers.WithWaitStrategy(wait.ForListeningPort("5432/tcp"))等端口就绪 - 对数据库 schema 初始化，封装带重试的函数：
for i := 0; i - 所有重试逻辑必须设上限（比如最多 5 次）和明确错误判断（只重试连接类错误，不重试语法错误）
测试写得越贴近真实部署环境，越容易暴露问题；但每多一个外部依赖，清理和等待逻辑就越容易出错。最常被忽略的是容器终止后的端口释放延迟——某些 Linux 内核下，Terminate() 返回后，端口仍处于 TIME_WAIT 状态，紧接着启动同端口新容器会失败。这时候得加一点缓冲，或者换用随机端口映射。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
