Kratos 不强制 ORM 但生产中首选 GORM，因其成熟度高、开发效率与调试友好性远超原生 database/sql；需配置 Logger、NamingStrategy、PrepareStmt 和 DisableForeignKeyConstraintWhenMigrating 四项关键参数。
直接说结论：Kratos 本身不绑定 ORM，但生产项目中 GORM 是最稳妥、文档最全、生态最成熟的选型；它不是“唯一解”，但对绝大多数业务场景，GORM 的开发效率、调试友好性和迁移能力远超原生 database/sql 或其他轻量 ORM。
为什么 Kratos 不强制 ORM，但实际都用 GORM？
Kratos 的设计哲学是“分层解耦”——Data 层只依赖接口抽象，不关心底层是 SQL 还是 NoSQL。这意味着你可以自由替换实现，但代价是：自己封装连接池、事务管理、日志埋点、错误包装、预编译语句复用等。而 GORM 已经把这些封装好了，且和 Kratos 的生命周期（app.Run / app.Stop）天然契合。
常见踩坑点：
- 误以为 “不用 ORM 更快” —— 实际上，手写
sql.DB查询若没做连接复用、上下文透传、错误 wrap，反而更容易出 timeout 或 panic - 在
NewData中直接panic(err)而非返回 error —— Kratos 启动流程会捕获并退出，但日志不带上下文，排查困难 - 忘记设置
gorm.Config{NamingStrategy: schema.NamingStrategy{SingularTable: true}}—— 默认复数表名（users），和多数建模习惯不符，容易查不到数据
GORM 初始化必须配的 4 个关键项
在 internal/data/data.go 的 NewData 函数里，仅靠 gorm.Open 连上数据库远远不够。以下配置缺一不可：
-
Logger: gormlogger.Default.LogMode(gormlogger.Info)—— 否则 SQL 完全不打印，调试时像盲人摸象 -
NamingStrategy: schema.NamingStrategy{SingularTable: true}—— 避免自动生成复数表名，和你定义的Userstruct 保持直觉一致 -
PrepareStmt: true—— 开启预编译语句复用，避免高频查询反复解析 SQL，性能提升明显（尤其在高并发 CRUD 场景） -
DisableForeignKeyConstraintWhenMigrating: true—— 开发期自动迁移时禁用外键检查，防止因 MySQL 版本或引擎差异报错（上线前再手动补约束）
示例片段：
db, err := gorm.Open(mysql.Open(dsn), &gorm.Config{
Logger: gormlogger.Default.LogMode(gormlogger.Info),
NamingStrategy: schema.NamingStrategy{SingularTable: true},
PrepareStmt: true,
DisableForeignKeyConstraintWhenMigrating: true,
})
模型定义（struct）和 GORM 标签怎么写才不翻车？
模型不是随便写个 struct 就能用的。GORM 依赖字段标签（tags）映射数据库列，漏写或写错会导致 Scan 失败、零值插入、甚至静默忽略字段。
必须写的标签：
-
ID uint+`gorm:"primaryKey"`—— 显式声明主键，否则 GORM 可能误判id字段为普通列 -
CreatedAt time.Time+`gorm:"column:created_at;autoCreateTime"`—— 指定列名 + 自动写入时间，别依赖默认行为 - 字符串字段加
`gorm:"size:255"`—— 防止 MySQL 默认VARCHAR(255)和 Go string 长度预期不一致 - 非空字段加
`gorm:"not null"`—— 和数据库约束对齐，避免插入时报错却找不到源头
反例：Username string `gorm:"column:username"` 缺少 not null 或长度限制，上线后可能因超长字符串被截断而不报错。
CRUD 逻辑该放在哪一层？别让 repo 变成 sql 脚本集合
Kratos 推荐分层：API → Service → Repo → Data。但很多人把所有 db.Create、db.Where 塞进 Repo，结果 repo 方法膨胀到 50 行，全是 GORM 链式调用。
更合理的方式：
- Repo 接口只暴露业务语义方法，比如
FindActiveUsersByDept(ctx, dept string) ([]*User, error)，而非FindByCondition(ctx, cond map[string]interface{}) - 具体实现里，用
db.Scopes()封装可复用的查询逻辑（如软删除过滤、租户隔离），而不是拼 if-else - 避免在 repo 里调用
db.Transaction—— 事务边界应由 Service 控制，repo 只负责单次操作 - 如果项目已引入
go-crud/gorm，优先用它的crud.New[Model]()，它把基础 CRUD 抽成方法，省掉重复的db.Create(&u)写法
复杂点在于：GORM 的链式调用（Where().Order().Limit()）看着简洁，但一旦嵌套条件多、需要动态拼接，就极易写出难以测试、无法复用的“胶水代码”。这时候宁可多写几行，也要把条件逻辑拆进私有 scope 函数。
