GORM单测不应直连真实DB，因违背快、隔离、可重复原则；官方无内置Mock支持，*gorm.DB难打桩，sqlmock又易漏Hook/Scope等逻辑；推荐用interface+依赖注入抽象数据访问层。
为什么 GORM 单测不能直接用真实 DB
因为单测要快、隔离、可重复，而连真实数据库会拖慢执行、依赖环境、产生脏数据。GORM 本身没有内置 Mock 支持，gorm.DB 是结构体指针，无法直接打桩；强行用 sqlmock 拦截底层 *sql.DB 又太底层，容易漏掉 GORM 的 Hook、Scope、Preload 等逻辑，导致测试通过但线上出错。
推荐方案：用 interface + 依赖注入替代直接 new DB
核心是把数据访问逻辑抽成接口，测试时传入 mock 实现。GORM 官方不强制你用 gorm.DB 做参数，但很多人写法是：
func GetUser(db *gorm.DB, id uint) (*User, error) {
var u User
return &u, db.First(&u, id).Error
}
这没法 mock。正确姿势是定义接口并接受它：
- 定义
UserRepo接口，含FindByID(id uint) (*User, error)等方法 - 生产实现里用
*gorm.DB调用真实操作 - 测试时写个
MockUserRepo，直接返回构造好的数据或错误 - 被测函数/服务通过参数或字段接收该接口，而非
*gorm.DB
这样既绕过 GORM 初始化开销，又完全控制返回值，还能验证调用顺序（配合 testify/mock 等）。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
如果非要用 gorm.DB 打桩：用 gomock + gormgen 生成 interface wrapper
硬要保留 *gorm.DB 类型签名？可以封装一层：
type GormClient interface {
First(dest interface{}, conds ...interface{}) *gorm.DB
Create(value interface{}) *gorm.DB
// ……只声明你实际用到的方法
}
然后让生产代码依赖这个接口，再用 gomock 生成 mock 实现。注意：gorm.DB 方法多数返回 *gorm.DB（链式调用），mock 时得返回自身或新 mock 实例，否则链式中断。常见坑：
-
First()返回*gorm.DB，但你要在其中设置Error字段或填充Value—— mock 实现必须能模拟这个行为 - 别 mock 全量方法，只 mock业务用到的，否则维护成本飙升
- GORM v2 的
Session()、Scopes()等会新建实例，mock 需考虑嵌套调用场景
更轻量的替代：testify/mock 或 go-sqlmock + 自定义 Queryer 封装
如果坚持走 SQL 层 mock，go-sqlmock 仍是主流选择，但必须绕过 GORM 的内部 query 构建。办法是：自己实现一个符合 gorm.Dialector 接口的测试用方言，把所有 Exec/Query 转发给 sqlmock，再用 gorm.Open(YourTestDialector, ...) 创建测试用 *gorm.DB。不过这属于高阶定制，绝大多数项目没必要——接口抽象已经覆盖 95% 场景。
真正容易被忽略的是：GORM 的 BeforeCreate、UpdatedAt 等自动字段行为，在 mock 接口里不会触发。如果你的业务逻辑严重依赖这些 Hook，那 mock 接口必须手动模拟它们，否则测试和运行时行为不一致。
