Go测试中必须mock数据库而非连真实库，因真实库会拖慢速度、引入环境依赖、导致数据污染和随机失败；sqlmock是主流方案，通过包装sql.Driver模拟SQL行为，支持断言SQL、参数检查和事务模拟，且需调用ExpectationsWereMet()验证。
Go 测试里为什么不能直接连真实数据库
真实数据库会拖慢测试速度、引入环境依赖、导致测试间数据污染，还可能因网络或权限问题让 go test 随机失败。尤其 CI 环境中，你没法保证 MySQL 实例一定在 localhost:3306 且账号有写权限。
所以必须 mock：不是“要不要”，而是“怎么 mock 得像、不漏测、不难维护”。
用 sqlmock 模拟 database/sql 接口最稳妥
sqlmock 是目前 Go 生态中最主流的 SQL 层 mock 方案，它不替换 *sql.DB，而是包装一个假的 sql.Driver，让 sql.Open("sqlmock", "") 返回可控的 *sql.DB，所有 Query/Exec 调用都走预设规则。
- 只 mock SQL 执行行为，保留原有
database/sql使用习惯，不用改业务代码 - 能断言 SQL 语句是否匹配正则（比如
mock.ExpectQuery(`^SELECT.*FROM users`)），也能检查参数绑定值 - 支持事务模拟：
mock.ExpectBegin()+mock.ExpectCommit()或ExpectRollback() - 记得调用
mock.ExpectationsWereMet()，否则未触发的期望会报错 —— 这是新手最常漏的一步
示例片段：
立即学习“go语言免费学习笔记（深入）”；
db, mock, _ := sqlmock.New()
defer db.Close()
mock.ExpectQuery(`SELECT id FROM users WHERE name = \?`).WithArgs("alice").WillReturnRows(
sqlmock.NewRows([]string{"id"}).AddRow(123),
)
rows, _ := db.Query("SELECT id FROM users WHERE name = ?", "alice")
// ... 处理 rows
if err := mock.ExpectationsWereMet(); err != nil {
t.Fatalf("unfulfilled expectations: %v", err)
}
别用内存 SQLite 当“轻量 mock”
有人图省事用 sqlite3 的 :memory: 数据库跑测试，看似隔离，实则隐患不少：
- SQL 方言差异：MySQL 的
INSERT IGNORE、PostgreSQL 的ON CONFLICT在 SQLite 里不生效或行为不同 - 类型隐式转换宽松：SQLite 对字段类型不严格，可能掩盖业务中本该报错的类型误用
- 无法验证 SQL 本身是否被正确构造 —— 你测的是“能不能跑通”，不是“有没有发对 SQL”
- 并发测试时
:memory:数据库不是进程级隔离，多个 test case 可能互相干扰
它适合做集成测试前的快速 smoke check，但不该替代 sqlmock 做单元测试。
当 ORM（如 GORM）介入时，mock 策略要分层
GORM 自带 gorm.io/gorm/migrator 和底层 dialector，直接 mock *gorm.DB 很容易掉进反射和链式调用陷阱。推荐做法是：
- 对 DAO 层函数（如
UserRepository.FindByID）做接口抽象，然后 mock 接口，而非 mock GORM 实例本身 - 如果必须测 GORM 构建的 SQL，仍用
sqlmock包住 GORM 底层的*sql.DB，GORM 会自动使用它 —— 设置方式：gorm.Open(mysql.Open(db), &gorm.Config{})，其中db是sqlmock.New()返回的 - 避免 mock
gorm.Session或Scopes：它们生命周期短、内部状态复杂，mock 成本远高于收益
关键点在于：mock 的边界要落在“你真正想验证的行为”上。如果函数只是封装了 db.Where(...).First()，那就 mock db；如果函数逻辑含复杂条件拼接，就该把拼 SQL 的部分抽成独立函数再单独测。
真正难的不是选哪个库，而是决定哪一层该被 mock、哪一层该被真实调用 —— 这取决于你这次测试想回答的问题：是“SQL 写对了吗”，还是“事务控制是否可靠”，或是“错误路径是否被覆盖”。没想清楚这点，mock 就容易变成测试套娃。
