Go测试中用内存数据库替代真实DB因启动快、易重置、无并发冲突；正确使用SQLite :memory:需复用同一*sql.DB实例并显式建表；sqlmock适用于纯SQL逻辑验证；Ent内存模式实为SQLite封装，需用enttest.NewMemoryClient并传schema。
Go测试中为什么用内存数据库代替真实DB
因为真实数据库启动慢、状态难重置、并发测试易冲突。内存数据库（如 sqlite 的 :memory: 模式、go-sqlmock、或 ent 的内存驱动）能秒级初始化，事务隔离干净，且不依赖外部服务。但要注意：它只模拟行为，不保证 SQL 兼容性——比如 PostgreSQL 特有函数在 SQLite 里根本不存在。
SQLite :memory: 在 Go test 中的正确打开方式
直接用 sql.Open("sqlite3", ":memory:") 是常见错误：它创建的是单连接内存 DB，每次 sql.Open 都是全新实例，无法跨 goroutine 共享 schema。正确做法是显式执行 CREATE TABLE 并复用同一 *sql.DB 实例。
- 测试前用
db, _ := sql.Open("sqlite3", ":memory:")初始化一次 - 立即执行建表语句（如
db.Exec("CREATE TABLE users(id INTEGER PRIMARY KEY, name TEXT)")） - 把
db传给被测函数或封装进 test helper 结构体 - 避免在每个 test case 里重新
Open—— 否则表结构丢失，报no such table
func TestUserCreate(t *testing.T) {
db, _ := sql.Open("sqlite3", ":memory:")
_, _ = db.Exec("CREATE TABLE users(id INTEGER PRIMARY KEY, name TEXT)")
repo := &UserRepo{db: db}
err := repo.Create("alice")
if err != nil {
t.Fatal(err)
}
}
用 sqlmock 拦截 SQL 调用做纯逻辑验证
当你只想验证 DAO 层是否生成了正确的 SQL、参数是否绑定正确，而完全不想碰数据库时，sqlmock 是更轻量的选择。它不执行 SQL，只校验语句模板和参数顺序，适合单元测试而非集成测试。
- 必须调用
mock.ExpectQuery()或mock.ExpectExec()预设期望，否则测试会 panic -
mock.ExpectQuery("SELECT.*").WithArgs(123)中正则需覆盖完整 SQL（空格、换行都算），建议用regexp.QuoteMeta转义字面量 - 测试末尾要调用
mock.AssertExpectations(t)，否则即使没匹配上也不会失败 - 不支持复杂驱动特性（如 pgx 的自定义类型、MySQL 的 multi-statement）
Ent 框架下启用内存模式的坑
Ent 自带 ent.Driver 接口，官方文档说 “支持内存驱动”，但实际只有 enttest 包提供 enttest.NewMemoryClient() —— 它底层仍是 SQLite :memory:，不是纯内存结构。如果你误以为它是无 SQL 的 mock，就会在写复杂查询时遇到 unsupported operation 错误。
- 必须用
enttest.NewMemoryClient(t, &ent.Schema{Edges: ...})显式传入 schema，否则 edge 关系不生效 - 不能混用
ent.Client和原生*sql.DB：前者会自动管理事务，后者需手动BeginTx - 内存 client 不支持
ent.Migrate的WithForeignKeys等高级选项，foreign key 约束默认关闭
真正难处理的是跨事务一致性：内存 DB 在 test 中看似“干净”，但一旦用了 defer db.Close() 或复用 connection pool，就可能因 GC 时机导致表被意外清空。最稳的方式是每个 test 函数独立 setup + teardown，哪怕多几行代码。
