直接 mock *sql.DB 会失败，因其是不可导出字段的具体类型，非接口，无法安全替换；正确做法是面向接口编程、用 sqlmock 拦截驱动或自定义接口+结构体 mock。
为什么直接 mock *sql.DB 会失败
Go 标准库的 *sql.DB 是一个高度封装的结构体，它不导出内部字段，也没有实现可被接口替换的“行为抽象”。你不能直接对 *sql.DB 做类型断言或赋值 mock 实例——它不是接口，而是一个具体类型。强行用 reflect 或 unsafe 替换字段不仅不稳定，还会在 Go 1.20+ 版本中因内部结构变更而崩溃。
正确做法是：**提前面向接口编程**。所有数据库操作必须通过接口（如 Queryer、Execer、自定义 DataStore）进行，而不是直接依赖 *sql.DB。
- 把业务逻辑中所有
db.QueryRow(...)、db.Exec(...)的调用，封装进一个接口方法里（例如GetUserByID(id int) (*User, error)） - 让该接口的生产实现接收
*sql.DB，测试实现则完全不依赖 SQL - 避免在函数签名或 struct 字段中硬编码
*sql.DB
用 sqlmock 拦截真实驱动调用（推荐快速验证）
sqlmock 不是 mock *sql.DB，而是 mock 底层 driver.Conn 行为，通过注册一个 fake driver，在 sql.Open("sqlmock", "") 时接管所有 SQL 执行路径。它适合验证 SQL 语句是否按预期生成、参数是否正确传递，但不适合模拟复杂业务逻辑分支。
关键点：
- 必须用
sqlmock.New()创建 mock 对象，并传给sql.Open—— 直接 new*sql.DB无效 - 每条 SQL 调用前必须显式声明期望：
mock.ExpectQuery("SELECT").WithArgs(123).WillReturnRows(...) - 测试末尾务必调用
mock.ExpectationsWereMet()，否则未匹配的 SQL 会被静默忽略（默认行为） - 不支持事务嵌套或高级特性（如
sql.Tx.StmtContext），遇到就 fallback 到接口 mock
示例片段：
db, mock, err := sqlmock.New()
if err != nil {
t.Fatal(err)
}
defer db.Close()
mock.ExpectQuery(`SELECT name FROM users WHERE id = \?`).WithArgs(42).
WillReturnRows(sqlmock.NewRows([]string{"name"}).AddRow("alice"))
user, err := FindUser(db, 42) // 你的函数
if err != nil {
t.Fatal(err)
}
if user != "alice" {
t.Fatal("expected alice")
}
if err := mock.ExpectationsWereMet(); err != nil {
t.Error(err)
}
自己定义数据访问接口 + 结构体 mock（适合复杂逻辑）
当需要模拟不同错误路径（如网络超时、唯一约束冲突）、状态机（如库存扣减成功/失败/重试）、或跨多表一致性逻辑时，sqlmock 表达力不足。这时应定义清晰的 interface，然后写轻量 struct 实现它。
比如：
type UserStore interface {
GetUserByID(ctx context.Context, id int) (*User, error)
CreateUser(ctx context.Context, u *User) (int, error)
}
type MockUserStore struct {
Users map[int]*User
Err error // 统一返回错误，或按方法设字段
}
func (m *MockUserStore) GetUserByID(ctx context.Context, id int) (*User, error) {
if m.Err != nil {
return nil, m.Err
}
return m.Users[id], nil
}
- 把
MockUserStore当作普通 struct 使用，无需反射或第三方库 - 可自由控制返回值、延迟、panic（用于测试 recover）、甚至记录调用历史（加
Called []string字段） - 注意：不要在 mock 实现里调用真实 DB；也不要让 mock 依赖外部状态（如全局变量），否则并发测试会打架
测试中传入 mock 的时机和依赖注入方式
Go 没有运行时 DI 容器，mock 必须在创建被测对象时显式传入。常见错误是：在函数内部 new *sql.DB，导致无法替换。
- 避免全局变量
var db *sql.DB—— 它让 mock 不可能 - 用构造函数接收接口：
NewUserService(store UserStore) *UserService - 若使用配置驱动初始化（如从 YAML 加载 DB URL），抽离初始化逻辑到单独函数，测试时跳过它，直接 new mock 并传入
- HTTP handler 测试中，可通过
httptest.NewRequest().WithContext(...)把 mock 注入 context，再由 handler 从中取 —— 但仅限简单场景；重度依赖建议改用依赖参数传递
最易被忽略的一点：mock 的生命周期要覆盖整个测试函数。别在子函数里 new mock 然后只测那一行——它和主逻辑不在同一实例上，等于没 mock。
