Go数据库测试核心是明确测什么与如何隔离：用testcontainers启临时真实DB做集成测试，sqlmock验证SQL拼写与驱动行为，二者分工——前者暴露类型、时区、约束等真实问题，后者确保DAO层SQL正确性及错误处理。
Go 语言做数据库测试，核心不是“能不能测”，而是“测什么”和“怎么隔离”。直接连真实数据库跑测试，会慢、不稳、难并行；全用 mock 又容易脱离实际 SQL 行为。最实用的方案是：用 testcontainers 启一个临时 PostgreSQL/MySQL 实例，配合 sqlmock 做单元级 SQL 协议层验证，二者分工明确。
什么时候该用 sqlmock？
sqlmock 不是模拟数据库，而是模拟 database/sql 的底层驱动行为——它拦截所有 db.Query、db.Exec 调用，检查 SQL 是否匹配预期，并返回伪造结果。适合验证：
- 你的 DAO 层是否拼出了正确的 SQL（比如 WHERE 条件、JOIN 顺序、参数绑定）
- 错误路径是否触发了预期的
err != nil分支 - 事务逻辑中
tx.Commit()/tx.Rollback()是否被正确调用
注意：sqlmock 不校验 SQL 语法、索引、外键约束或执行计划。它只管“你发了什么，你有没有处理返回”。如果 SQL 字符串里写错了表名，sqlmock 不报错——除非你显式要求它匹配该字符串。
mock.ExpectQuery(`SELECT id, name FROM users WHERE status = /$1`).
WithArgs("active").
WillReturnRows(sqlmock.NewRows([]string{"id", "name"}).AddRow(1, "alice"))
为什么不能只靠 sqlmock？
因为很多问题只有真实数据库才能暴露：
立即学习“go语言免费学习笔记（深入）”；
-
jsonb字段解析失败（Go struct tag 和 PostgreSQL 类型不匹配） - 时间字段时区转换异常（
time.Time存入TIMESTAMP WITH TIME ZONE后读出来偏移不对） - 唯一约束冲突没被正确捕获（mock 返回
sql.ErrNoRows，但真实 DB 报的是pq.Error或mysql.MySQLError） - GORM 或 sqlx 的扫描逻辑在复杂 JOIN 下漏字段
这类问题必须走真实 SQL 执行。此时 testcontainers 就派上用场：它在测试启动时拉起一个 Docker 容器里的数据库，测试结束自动销毁。比本地装 DB 干净，比 CI 上配环境简单。
如何让 testcontainers 真实又可控？
关键不是“完全模拟生产”，而是“控制初始化状态”。做法是：
- 用
ContainerRequest.FromDockerfile或官方镜像（如postgres:15-alpine）启动容器 - 通过
WithEnv设置POSTGRES_DB=testdb，避免连错库 - 在测试前用
pg_dump或 SQL 文件执行 schema 初始化（不要依赖迁移脚本，防止测试间污染） - 每个测试函数用独立的
db连接，且测试末尾执行TRUNCATE TABLE x, y, z RESTART IDENTITY CASCADE
别省略 RESTART IDENTITY ——否则自增主键会在多次测试中越滚越大，导致某些边界 case 漏测。也别用 DROP DATABASE，PostgreSQL 不允许在连接中删当前库。
真实测试中容易忽略的三个点
一是连接池配置。测试里常设 db.SetMaxOpenConns(1) 图省事，但掩盖了连接竞争 bug；建议保持和线上一致（如 10），并在测试后加 db.Close() 防止端口泄漏。
二是时区。PostgreSQL 默认用系统时区，而 Go time.Now() 是本地时区。测试时间相关逻辑前，统一设 PGTZ=UTC 和 time.Local = time.UTC。
三是错误类型断言。不要写 if err != nil && strings.Contains(err.Error(), "duplicate key")，而要用具体驱动的 error 类型判断，比如 if pqErr, ok := err.(*pq.Error); ok && pqErr.Code == "23505"。