go-sqlmock不能直接替换sql.db因返回sqlmock.sqlmock接口，需调用.db()获取代理sql.db；匹配带参查询须用正则避免占位符重排；事务需显式expectbegin/commit；测试中应独立初始化、注入并关闭mock。
Go-sqlmock 为什么不能直接替换 *sql.DB 实例
因为 sqlmock.New() 返回的是 sqlmock.Sqlmock 接口，不是 *sql.DB；而你的微服务里实际依赖的是 *sql.DB（比如通过构造函数注入或全局变量）。直接传 sqlmock.Sqlmock 会编译失败。
正确做法是：用 sqlmock.New() 创建 mock 对象后，调用其 .DB() 方法获取包装后的 *sql.DB 实例——它内部代理了真实 database/sql 调用，并将 SQL 执行转给 mock 处理。
-
mock, db := sqlmock.New()是标准初始化方式，db就是能直接传给业务层的*sql.DB - 别写成
db, _ := sqlmock.New()—— 这样拿到的是接口，无法传给需要*sql.DB的函数 - 如果服务中使用了
sqlx.DB，需用sqlx.NewDb(db, "postgres")包一层，其中db就是上面的*sql.DB
如何让 mock 正确匹配带参数的 SELECT 查询
Go-sqlmock 默认对 SQL 字符串做**精确字符串匹配**，但 Go 的 database/sql 在预处理时可能重排参数占位符（尤其用 , 的 PostgreSQL），或驱动自动改写语句（如加 schema 前缀）。结果就是 mock.ExpectQuery("SELECT * FROM users WHERE id = ?").WithArgs(123) 匹配失败。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 优先用
mock.ExpectQuery(regexp.QuoteMeta("SELECT * FROM users WHERE id = $1"))避免正则元字符干扰 - 更稳妥的方式是启用正则匹配：
mock.ExpectQuery(`^SELECT \* FROM users WHERE id = \$1$`).WithArgs(123) - 若用 MySQL，占位符是
?，注意不要混用：ExpectQuery(`^SELECT \* FROM users WHERE name = \?$`).WithArgs("alice") - 执行查询后务必调用
mock.AssertExpectations(t)，否则未命中的期望不会报错
事务场景下 Begin / Commit 怎么打桩
微服务常涉及事务逻辑，比如先 INSERT 再 UPDATE，最后 Commit。但 sqlmock 默认不拦截事务控制语句——Begin()、Commit()、Rollback() 调用本身不会触发任何期望校验，容易漏测。
- 必须显式声明事务期望：
mock.ExpectBegin()、mock.ExpectCommit()或mock.ExpectRollback() - 如果业务代码在
defer tx.Rollback()后又调用了tx.Commit()，mock 会因重复 Rollback 报错；需确保测试路径只走一条分支 - 事务内嵌套查询要按顺序设置期望：先
ExpectBegin()，再ExpectQuery(...)，最后ExpectCommit() - 注意：mock 不模拟事务隔离级别或并发行为，仅验证调用序列和参数
集成进 Gin / gRPC 微服务测试时的生命周期管理
微服务通常启动 HTTP/gRPC server 后才初始化 DB 客户端，而测试时你得在 handler 执行前把 mock *sql.DB 注入进去。硬编码替换全局变量或结构体字段容易污染其他测试用例。
- 推荐用依赖注入：把
*sql.DB作为服务结构体字段，在 test 中 new service 时传入 mock*sql.DB - 避免在
TestMain里初始化全局 mock，不同测试并行运行会冲突；每个测试函数内独立sqlmock.New() - Gin 测试可构造
httptest.NewRecorder()+ 自定义gin.Engine，然后用engine.ServeHTTP()触发 handler；关键是在 handler 调用前完成 DB 替换 - gRPC 测试建议用
grpc.NewServer()+testify/mock模拟下游服务，DB 层仍走sqlmock，两者互不干扰
最易被忽略的是：mock 对象必须在测试结束前调用 mock.Close()（或让 db.Close() 触发），否则可能残留 goroutine 导致测试超时或 panic。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
