Go语言SQLite单元测试Mock技巧

用 sql.Open("sqlite3", ":memory:") 即可创建独立、快速、无文件的内存数据库用于单元测试，需避免误写驱动名、复用实例、遗漏关闭及事务未提交等问题。

用 sqlite3.Open 打开 :memory: 就够了

Go 的 sqlite3 驱动（mattn/go-sqlite3）原生支持内存数据库，不需要额外 mock 层。调用 sql.Open("sqlite3", ":memory:") 创建的连接完全独立、无文件依赖、启动快——这就是最轻量也最真实的单元测试底座。

常见错误是误写成 "mem" 或 ":mem:"，SQLite 只认 :memory: 这个固定字符串；另一个坑是复用同一个 *sql.DB 实例跑多个测试，导致表结构或数据互相污染。

• 每个测试函数内单独调用 sql.Open + db.Close()
• 建表语句必须在 db.Exec 中显式执行，内存库不保留 schema 跨连接
• 如果用了 gorm 或 sqlc，注意它们的 AutoMigrate / Exec 也要走这个 db 实例

别碰 sqlmock，它和 SQLite 冲突

sqlmock 是为模拟 SQL 协议层设计的，但 mattn/go-sqlite3 是直接调用 C 库的本地驱动，绕过了标准 database/sql 的协议抽象。一旦你注册了 sqlmock 驱动名（比如 "sqlmock"），再用 sql.Open("sqlmock", ...)，就根本连不到 SQLite —— 报错通常是 "unknown driver sqlmock" 或 panic 在 init() 阶段。

真正需要 mock 的，从来不是数据库本身，而是你的业务逻辑对 DB 的调用边界。比如 DAO 层返回 error 的场景，应该靠构造特定的 *sql.Rows 或提前 db.Exec("DROP TABLE xxx") 触发失败，而不是拦截 SQL 字符串。

• 删掉所有 _ "github.com/DATA-DOG/go-sqlmock" 导入
• 不要注册新驱动名，坚持用 "sqlite3"
• 想控制返回值？用 db.QueryRow("SELECT ? FROM sqlite_master WHERE 0").Scan(&v) 这类总失败的语句触发 error 分支

事务隔离靠 db.Begin()，不是靠并发

内存数据库的 :memory: 实例默认不共享状态，但如果你在单个测试里手动开了事务却忘了 Rollback() 或 Commit()，后续 db.Query 可能卡住或返回旧数据——这不是并发问题，是事务没结束。

更隐蔽的坑是：SQLite 的内存库在事务中创建的临时表（CREATE TEMP TABLE）只在该事务内可见，而普通 CREATE TABLE 在整个连接生命周期有效。测试时若混用，容易出现 “表不存在” 错误，尤其在使用 sqlc 生成代码时，它默认不加 TEMP 前缀。

• 测试函数末尾务必 defer tx.Rollback()，哪怕你打算 Commit()，也要用 if tx != nil { tx.Rollback() } 防 panic
• 避免在事务里建非临时表；如需预置数据，统一在 tx.Exec("CREATE TABLE ...") 后立刻 INSERT
• 检查 sqlc 的 emit_prepared_queries: false 配置，防止它生成的语句意外依赖连接级状态

注意 sqlite3 构建标签影响 CGO

如果你的 CI 或某些机器禁用了 CGO（CGO_ENABLED=0），mattn/go-sqlite3 直接编译失败，报错类似 "no buildable Go source files"。这不是测试写得不对，是构建环境没配对。

本地开发通常没问题，但 Docker 多阶段构建、Alpine 镜像、或某些 IDE 的测试 runner 可能默认关 CGO。这时候强行切到纯 Go 的 SQLite 实现（比如 modernc.org/sqlite）反而更麻烦——它的 API 不兼容 database/sql 标准，且不支持 WAL 模式等关键特性。

• CI 中明确设 CGO_ENABLED=1，并安装 gcc 和 musl-dev（Alpine）或 build-essential（Debian）
• 不用 go test -tags sqlite 这类自定义 tag，mattn/go-sqlite3 依赖的是 CGO 本身，不是构建标签
• 如果真不能开 CGO，接受降级：改用文件数据库（/tmp/test.db），每次测试前 os.Remove，比硬切驱动更稳

最常被忽略的其实是时间——内存数据库初始化极快，但如果你在测试里反复 sql.Open + db.Close() 上百次，GC 压力和 fd 泄漏会慢慢显现。别省那几行 defer db.Close()，也别图方便在 TestMain 里全局复用一个 db。