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: 数据库跑测试，看似隔离，实则隐患不少：
家电公司网站源码是一个以米拓为核心进行开发的家电商城网站模板，程序采用metinfo5.3.9 UTF8进行编码，软件包含完整栏目与数据。安装方法：解压上传到空间，访问域名进行安装，安装好后，到后台-安全与效率-数据备份还原，恢复好数据后到设置-基本信息和外观-电脑把网站名称什么的改为自己的即可。默认后台账号：admin 密码：132456注意：如本地测试中127.0.0.1无法正常使用，请换成l
- 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 就容易变成测试套娃。
