在iris mvc中，应于main.go或app.go中全局单例初始化gorm/xorm引擎，通过app.registervalue注入并用registeroninterrupt注册关闭逻辑；严禁每次请求新建实例，须配置连接池参数，xorm需调engine.sync2建表，确保线程安全与资源正确释放。
怎么在Iris MVC里初始化GORM或XORM引擎
你不能把ORM实例塞进控制器结构体里直接用，它得是全局可访问、线程安全的单例。Iris本身不管理ORM生命周期，得你自己注册并确保关闭时机正确。
常见错误是每次请求都新建一个*gorm.DB或*xorm.Engine，导致连接泄漏、事务混乱、性能骤降。
- 在
main.go或app.go中初始化一次，存到全局变量或通过app.RegisterValue注入 - 用
iris.RegisterOnInterrupt注册关闭逻辑，避免进程退出时连接未释放 - GORM推荐用
sql.Open后调db.SetMaxOpenConns和db.SetMaxIdleConns，别依赖默认值（尤其SQLite或MySQL高并发场景） - XORM初始化后必须调
engine.Sync2(new(User))建表，否则Get/Insert会静默失败
repositories层怎么封装CRUD方法才不踩坑
repositories不是简单包装ORM调用，它的核心职责是：统一错误处理、隐藏SQL细节、约束参数边界、适配不同ORM行为差异。直接把orm.Where(...).Find(&users)扔进controller，等于把数据层污染到路由层。
典型问题包括：没校验id是否为正数就传给Get、Update时漏掉UpdatedAt字段、Delete没加软删除条件。
- 所有方法接收
context.Context，便于后续加超时或取消控制 - ID类参数强制用
int64或uint64，避免int在32位系统溢出 - 查询方法返回
([]User, error)而非*[]User，防止nil切片panic - 更新操作必须显式指定
UpdatedAt: time.Now()，GORM不会自动更新该字段除非你配置autoUpdateTime
service层如何协调多个repository并保持事务一致
Iris不提供声明式事务支持，事务必须由service层手动控制。跨repository操作（比如扣余额+写日志）若不在同一事务里，极易出现数据不一致。
最容易被忽略的是：GORM的Transaction对象不能跨goroutine传递，也不能在中间件里开启后交给controller继续用——事务上下文只在当前函数作用域有效。
- 用
db.Transaction(func(tx *gorm.DB) error { ... })包裹整个业务逻辑，别拆成多个tx.Create调用再拼error - 如果用了XORM，得自己管理
session.Begin()/session.Commit()/session.Rollback()，且必须defer保证回滚 - 事务内不要调用其他service方法，除非它们明确接受
*gorm.DB或*xorm.Session作为参数 - 日志、缓存等副作用操作放在事务提交成功后执行，避免事务回滚但缓存已更新
为什么controller里不该直接调用ORM方法
看似省事的写法：users, _ := orm.Where("status = ?", 1).Find(&[]User{})，实际破坏了MVC分层契约，让测试、Mock、替换ORM变得极其困难。
更隐蔽的问题是：controller里混入数据库错误处理逻辑（比如if err != nil && errors.Is(err, gorm.ErrRecordNotFound)），导致业务规则和数据访问耦合，后续加审计、重试、熔断时无从下手。
- controller只负责解析输入（
c.URLParamInt、c.ReadJSON）、调用service方法、返回响应（c.JSON） - 所有数据库错误应在repository层转为自定义错误类型（如
ErrUserNotFound），service层决定是否透传，controller只做HTTP状态码映射 - 分页参数
page/size的校验必须在controller完成，别丢给repository去判断size > 100 - 前端传来的ID、时间戳、枚举值，必须在controller层做基础校验（非空、范围、格式），repository只信service传来的数据
