Revel 框架需手动集成 GORM 连接 MySQL，必须在 app.Init() 初始化带连接池的 *gorm.DB 并注入请求上下文，禁止全局共享、重复 Open 或硬编码事务，且须在 panic filter 中主动 rollback 事务。
Revel 框架本身不内置 ORM，连接 MySQL 必须显式引入驱动和数据库层（如 GORM），不能靠框架自动配置。直接在 app/init.go 里调用 sql.Open 或裸用 gorm.Open 而不管理生命周期，会导致连接泄漏、并发 panic 或路由间 DB 实例污染。
初始化 GORM 连接池要放在 app.Init() 里
Revel 的启动流程中，app.Init() 是唯一安全执行全局初始化逻辑的位置。GORM v2+ 的 *gorm.DB 实例自带连接池，但必须在这里完成创建、配置和赋值给包级变量，否则后续 filter 或 controller 无法稳定访问。
- 不要在 controller 方法里每次请求都
gorm.Open—— 连接池不会复用，CPU 和 socket 耗尽得很快 - 必须显式调用
db.Exec("SELECT 1")或db.Prepare("SELECT ?")做一次探活，否则首次请求可能因 DNS 解析或网络抖动失败 - 若用 MySQL，DSN 中务必包含
parseTime=true&loc=Local，否则time.Time字段会解析成零值
DB 实例不能全局单例共享给所有请求
GORM 的 *gorm.DB 不是线程安全的写入目标，尤其当启用 Session、Transaction 或自定义 Context 时。Revel 的并发模型下，多个请求共用一个 DBMaster 变量会导致事务隔离失效、Preload 错乱、甚至 panic: "invalid memory address"。
- 正确做法是：用 Revel 的
InterceptFunc在BEFORE阶段把对应 DB 实例注入c.Params.Values或自定义 context key - 模型方法（如
User.FindByID(c, id)）应从 context 取 DB，而不是直接引用包级DBMaster - 避免在
app.DB上调用Session(&sessionOpts)后又把它塞进全局变量——session 状态会跨请求残留
事务必须绑定到当前请求上下文
Revel 没有自动事务管理，db.Transaction() 返回的临时 *gorm.DB 只对该次调用有效。若在 filter 里开启事务但没传给 controller，或者 controller 忘记用 tx.Create() 而误用 DBMaster.Create()，数据就绕过事务直接落库。
- 推荐在 filter 中判断是否需事务（如 POST /orders），用
c.Params.Set("tx", tx)注入 - controller 中统一用
tx := c.Params.Get("tx")获取，类型断言为*gorm.DB - 务必在 defer 中调用
tx.Commit()或tx.Rollback()，且只在 HTTP handler 返回前执行 - 不要在 model 层硬编码
DBMaster.Transaction()—— 会破坏上层对事务边界的控制
最易被忽略的是错误恢复路径：当 controller 中发生 panic，Revel 默认 recover 并返回 500，但此时已开启的事务不会自动 rollback。必须在自定义 panic filter 里检查 c.Params.Get("tx") 是否存在，并主动调用 Rollback()。这点在分片场景下尤其危险——主库回滚了，分片库还挂着未提交的变更。
