SQLMock 比 GoMock 更适合数据库测试，因其直接拦截 database/sql 底层驱动调用，无需抽象接口、自动处理复杂参数与边界行为，且支持全驱动兼容、内存级高效、SQL 精确匹配与事务完整模拟。
SQLMock 为什么比 GoMock 更适合数据库测试
GoMock 本质是接口打桩工具，它要求你先定义 *sql.DB 的抽象接口（比如 DataStore），再生成 mock。但 *sql.DB 本身不是接口，且其方法（Query、Exec、Begin）参数类型复杂（含 context.Context、...interface{}），手动抽象极易漏掉边界行为（如事务回滚、连接池超时）。SQLMock 直接拦截 database/sql 底层驱动调用，无需改业务代码结构，mock 行为与真实 DB 交互路径一致。
常见错误现象：panic: sql: expected 2 arguments, got 1 —— 这往往是因为用 GoMock 模拟 Query 时没处理可变参数，或上下文参数位置错乱；而 SQLMock 只需声明「这条 SQL 会返回什么」，参数校验由它自己完成。
- 使用场景：单元测试中隔离外部依赖，验证 DAO 层逻辑（如条件拼接、Scan 映射、错误分支）
- 性能影响：SQLMock 是内存级拦截，无网络/IO 开销，比启动真实 PostgreSQL 容器快 100+ 倍
- 兼容性：支持所有实现了
database/sql/driver的驱动（pgx、mysql、sqlite3），但注意pgx/v5需用sqlmock.New()而非旧版sqlmock.NewWithDSN()
初始化 SQLMock 时必须绕开 driver.Register
直接调用 sql.Open("postgres", dsn) 会触发驱动注册，而 SQLMock 要求使用它自己的驱动名（如 "sqlmock"）。如果忘了这步，测试会连到真实数据库，或者报错 sql: unknown driver "sqlmock" (forgotten import?)。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 在测试文件顶部显式导入：
_ "github.com/DATA-DOG/go-sqlmock"（下划线触发 init 注册） - 用
sqlmock.New()创建 mock 对象，它返回*sql.DB和sqlmock.Sqlmock - 把 mock
*sql.DB注入你的 DAO 结构体，不要复用生产环境的sql.Open调用 - 禁止在测试里写
sql.Open("postgres", "...")—— 即使 DSN 是假的，也会尝试建连
示例关键行：
db, mock, err := sqlmock.New()<br>if err != nil {<br> t.Fatal(err)<br>}<br>defer db.Close()
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
ExpectQuery 和 ExpectExec 的匹配逻辑很严格
SQLMock 默认做**全字符串精确匹配**。写 mock.ExpectQuery("SELECT id FROM users")，但代码里实际执行的是 SELECT id FROM users WHERE name = ?，测试就失败 —— 它不会帮你忽略 WHERE 条件或空格差异。
容易踩的坑：
- 参数占位符不统一：
mysql用?，postgres用$1，SQLMock 的 expect 必须和你代码中实际拼出的 SQL 一致 - 换行/缩进导致不匹配：用
regexp.QuoteMeta()包裹 SQL 字符串，或直接用正则模式：mock.ExpectQuery(regexp.QuoteMeta("SELECT * FROM orders")).WillReturnRows(...) - 忘记调用
mock.ExpectClose()：如果 DAO 方法里调用了rows.Close()，而 mock 没 expect，测试会 panic - 事务未 commit/rollback：若代码走
tx.Commit()，mock 必须对应mock.ExpectCommit()，否则报there is a remaining expectation which was not matched
Scan 到 struct 时字段名大小写必须和 Rows.Columns() 一致
SQLMock 返回的 mock rows 默认列名是小写（如 "id"、"created_at"），但 Go struct tag 里写 json:"ID" 或 db:"Id" 不影响 Scan —— 真正影响的是 rows.Scan() 时传入的指针顺序，以及 sql.Rows.Columns() 返回的原始名称。
典型问题：sql: Scan error on column index 0, name "ID": unsupported Scan, storing driver.Value type []uint8 into type *int64，这往往是因为字段类型不匹配，而非大小写问题；但更隐蔽的是：mock 返回列名是 "user_id"，struct 字段叫 UserID 且有 db:"user_id" tag，却仍 scan 失败 —— 因为 SQLMock 不解析 tag，它只按 Columns() 名字顺序塞值。
- 安全做法：mock rows 时显式指定列名，和 struct 字段名保持一致：
sqlmock.NewRows([]string{"id", "name"}).AddRow(1, "alice") - 避免用
map[string]interface{}接收结果再赋值，这种写法绕过类型检查，容易掩盖字段错位 - 如果 DAO 用了
sqlx.StructScan，确保 mock 的列名和 struct tag 完全对应（包括下划线/驼峰），因为sqlx会根据 tag 反查列名
事情说清了就结束
