不能直接用 sqlmock.Mock 接口对接 sql.DB，因它非 sql.DB 类型；须用 sqlmock.New() 创建 mock DB 实例并注入业务代码，且需检查错误、调用 ExpectationsWereMet()。
为什么不能直接用 sqlmock.Mock 对接 *sql.DB
因为 sqlmock.Mock 本身不是 *sql.DB，它只提供一个模拟的 sqlmock.Sqlmock 接口实例，必须通过 sqlmock.New() 创建，并且要手动把 mock 的 *sql.DB 注入到你的业务代码中。常见错误是试图对已有真实 *sql.DB 调用 Mock 方法——这会 panic，因为真实 DB 没有 Mock 字段。
正确做法是：在测试中用 sqlmock.New() 得到一对 *sql.DB 和 sqlmock.Sqlmock，再把前者传给被测函数（比如通过构造函数、参数或依赖注入容器）。
- 务必检查
db, mock, err := sqlmock.New()的err，忽略它会导致后续 ExpectXXX 失效却无提示 - 测试末尾必须调用
mock.ExpectationsWereMet()，否则未执行的 expect 不报错，容易漏覆盖 - 如果业务层用的是
*gorm.DB，不要对*sql.DB做 expect —— GORM v2 默认用session封装，SQL 可能被重写或拆分，应改用gorm.io/gorm/migrator或更稳妥的gormtest方案
如何让 sqlmock 正确匹配带占位符的查询语句
sqlmock 默认使用正则匹配 SQL，而 Go 的 database/sql 驱动（如 mysql 或 postgres）会把 ? 或 $1 替换为具体值再发给数据库。但 sqlmock.ExpectQuery() 期望你传入原始 SQL 模板，不是插值后的字符串。
例如业务代码执行：db.Query("SELECT name FROM users WHERE id = ?", userID)，测试里应写：mock.ExpectQuery("SELECT name FROM users WHERE id = \\\\?").WithArgs(123)（注意 \\? 是转义后的字面量问号）。
立即学习“go语言免费学习笔记（深入）”；
- PostgreSQL 驱动用
$1占位符，expect 时写"\$1"（双引号内需反斜杠转义） - MySQL 驱动用
?，expect 中写"\\?"；SQLite 同理 - 避免用
ExpectQuery(".*users.*")这类模糊正则——它可能误匹配其他语句，导致测试脆弱 - 若 SQL 中有换行或空格差异，用
regexp.QuoteMeta()包裹原始语句再拼接，确保字面量精确匹配
Mock 扫描结构体时为何 Scan() 总返回 “wrong number of columns”
这是最常踩的坑：调用 rows := mock.NewRows([]string{"id", "name"}) 后，必须用 rows.AddRow(1, "alice") 提供与列名数量、类型严格一致的数据行。如果结构体字段数（比如 type User struct { ID int; Name string }）和 AddRow() 传参个数不等，rows.Scan(&u) 就会报这个错。
更隐蔽的情况是字段类型不匹配：比如 DB 列是 INT，但 AddRow("1", "alice") 传了字符串，Scan() 无法自动转换，也会失败。
- 列名顺序必须和
SELECT字段顺序完全一致，不能只看字段名 - 用
sql.NullString、sql.NullInt64等类型接收可能为 NULL 的列，对应AddRow(sql.NullString{String: "x", Valid: true}) - 如果结构体嵌套或用了
sql.Scanner自定义类型，mock 行数据必须满足其Scan()方法签名，否则 panic
替代方案：什么时候该放弃 sqlmock，改用内存数据库
当你的 SQL 包含复杂 JOIN、子查询、窗口函数，或依赖数据库特有行为（如 MySQL 的 INSERT ... ON DUPLICATE KEY UPDATE），sqlmock 的正则匹配和静态响应就力不从心了。此时可切到轻量级内存数据库，比如 sqlite（用 :memory: DSN）或 pgxpool + testcontainers-go 启一个临时 PostgreSQL 容器。
sqlite 示例：sql.Open("sqlite3", ":memory:")，然后用真实 CREATE TABLE 和 INSERT 初始化 schema 和测试数据，业务代码完全不用改。
- sqlite 不支持某些 PostgreSQL/MySQL 语法（如
RETURNING），选型前先确认兼容性 - testcontainers 启停慢、依赖 Docker，适合集成测试而非单元测试
- 如果只是想绕过网络 I/O，但又需要事务隔离，可用
github.com/mattn/go-sqlite3的_ "github.com/mattn/go-sqlite3"+:memory:，启动快且零外部依赖
真正难 mock 的从来不是 SQL 本身，而是数据库状态机行为：比如并发事务下的锁等待、死锁检测、连接池耗尽时的 timeout。这些只有真实驱动+内存库才能逼近。
