go-sqlmock 在微服务测试中易“假成功”是因为未拦截实际 SQL 执行，根本原因是 ORM（如 GORM）未注入 mock 的 *sql.DB 实例，导致 mock 失效；需在依赖注入上游创建 mock 并穿透 ORM 层，正确匹配 SQL、显式期望事务、避免复用 mock 实例，并手动触发 gorm.ErrRecordNotFound 等特定错误。
为什么 go-sqlmock 在微服务测试里容易“假成功”
直接用 go-sqlmock 替换真实 DB 实例，但测试通过、上线却报 sql: no rows in result set 或事务不回滚——根本原因是没拦截到实际执行的 SQL。微服务里常通过 db.DB（如 *gorm.DB 或自封装的 Repository）间接调用底层 *sql.DB，而 go-sqlmock 只能 mock *sql.DB 实例本身。如果代码里用了 GORM、SQLX 等 ORM/工具层，且未显式传入 mock 的 *sql.DB，mock 就完全失效。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 确认你的数据访问层最终调用的是
database/sql原生接口（比如db.QueryRow()、db.Exec()），否则必须穿透 ORM 层注入 mock*sql.DB - 不要在全局变量或单例中初始化真实
*sql.DB后再试图替换——mock 必须在依赖注入链最上游创建并传入 - GORM v2 要用
gorm.Open(mysql.New(mysql.Config{Conn: mockDB}))，而不是gorm.Open(mysql.Open(...))，后者会新建连接，绕过 mock
如何让 sqlmock 正确匹配带参数占位符的 SQL
微服务里 SQL 多含命名参数（:id）、问号占位符（?）或 GORM 自动生成的语句（SELECT * FROM users WHERE id = ?），而 sqlmock.ExpectQuery() 默认只做字符串精确匹配，一有空格、换行或参数格式差异就失败。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
sqlmock.AnyArg()替代具体参数值，例如：mock.ExpectQuery(`SELECT \* FROM users`).WithArgs(sqlmock.AnyArg()).WillReturnRows(rows) - 对 GORM 生成的 SQL，启用日志看真实语句：
gorm.Config{Logger: logger.Default.LogMode(logger.Info)}，再用regexp.QuoteMeta()转义后传给ExpectQuery() - 避免写死字段顺序：GORM SELECT 可能自动加
ORDER BY或调整字段顺序，用mock.ExpectQuery(regexp.QuoteMeta("SELECT id, name FROM users")).WillReturnRows(...)更稳
事务和连接池场景下 sqlmock 的常见崩点
微服务高频使用 db.Begin()、tx.Commit() 和连接池复用，而 sqlmock 默认不校验事务行为——tx.Commit() 成功返回但没真正触发 Expect，或并发测试时多个 goroutine 共享同一 mock 实例导致期望冲突。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 为每个测试用例单独调用
sqlmock.New()，别复用 mock 实例；测试结束必须调用mock.ExpectationsWereMet()，否则漏掉未触发的 Expect 不报错 - 事务操作要显式 Expect：
mock.ExpectBegin()、mock.ExpectCommit()或mock.ExpectRollback()，否则tx.Commit()返回 nil 但 Expect 不被消耗 - 避免在测试中调用
db.SetMaxOpenConns(1)等连接池配置——mock 不实现连接池逻辑，仅模拟单次调用，设限反而引发超时或阻塞
在 Gin + GORM 微服务中注入 mock 的最小可行路径
典型结构是 handler → service → repository，repository 持有 *gorm.DB。若 repository 初始化时硬编码了 gorm.Open(...)，mock 就无法介入。必须把 DB 实例作为依赖传入，而非内部创建。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- repository 接口定义保持原样，构造函数接收
*gorm.DB：func NewUserRepo(db *gorm.DB) *UserRepo { return &UserRepo{db: db} } - 测试中构建 mock：
db, mock, err := sqlmock.New() assert.NoError(t, err) defer db.Close() <p>gormDB, err := gorm.Open(mysql.New(mysql.Config{Conn: db}), &gorm.Config{}) assert.NoError(t, err)</p><p>repo := NewUserRepo(gormDB) - Handler 层测试不用启动 Gin 服务器，直接构造 service 并注入 mock repo，验证业务逻辑分支（如用户不存在时返回 404）即可
最易忽略的是：GORM 的 First()、Find() 等方法在无结果时不 panic，但会设置 rowsAffected=0，此时要检查 errors.Is(err, gorm.ErrRecordNotFound)，而不是只断言 err == nil。mock 返回空行集时，这个 error 不会自动产生，需手动用 mock.ExpectQuery().WillReturnError(gorm.ErrRecordNotFound) 触发。
