用 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 字符串。
立即学习“go语言免费学习笔记（深入）”；
- 删掉所有
_ "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。
