Revel中GORM多DB实例需在启动时预建独立*gorm.DB并命名，通过filter+context在BEFORE阶段动态路由，DAO层用GetDB()安全消费，事务需显式开启，严禁用全局map模拟ThreadLocal。
Revel里GORM多DB实例怎么初始化才不踩坑
Revel本身不提供数据源路由能力，GORM也不支持运行时替换全局gorm.DB单例。硬改gorm.DB会导致连接池混乱、事务失效、goroutine泄漏。必须在应用启动时就预建多个独立的*gorm.DB实例，并绑定唯一标识。
关键点有三个：
- 每个分片库用独立的
gorm.Open()调用，不要复用同一个gorm.Config变量（避免连接池参数被覆盖） - 显式设置
Config.Name或用全局变量命名，比如DBShard1、DBShard2，后续路由逻辑靠这个区分 - 连接池参数必须单独配置，尤其
MaxOpenConns和MaxIdleConns——别让所有分片共用同一套默认值，否则高并发下某个分片会抢光连接
请求级动态路由靠filter+context传递
Revel没有Spring那种AbstractRoutingDataSource抽象层，没法靠AOP自动切数据源。你得自己写一个revel.InterceptFunc，在BEFORE阶段解析请求上下文（比如URL路径、Header里的X-Shard-Key、或Session中的用户ID哈希），然后把选中的*gorm.DB实例塞进revel.Controller.Request.Context()里。
常见错误现象：
- 直接在filter里调
c.RenderArgs["db"] = DBShard1——这只能传给模板，DAO层拿不到 - 没用
context.WithValue()包装新context，导致下游调用链丢失DB实例 - 路由逻辑写在
AFTER拦截器里——太晚了，SQL已经执行完了
正确做法是：在filter中构建带DB的context，再用c.Params.Set("ctx", newCtx)或自定义中间件透传。
GORM模型层怎么安全消费路由后的DB
不能让每个model都去从context里取*gorm.DB，那样代码重复又易错。推荐封装一个GetDB(c *revel.Controller) *gorm.DB工具函数，内部从c.Params.Get("ctx")或c.Request.Context()里解包。所有DAO方法第一行就调它，拿到DB后立刻开始操作。
注意两个边界条件：
- 如果没命中任何分片规则，
GetDB必须返回默认库（如主库）或panic，不能静默返回nil——否则db.Create()会panic在底层，堆栈难定位 - 事务必须显式开启：
tx := db.WithContext(ctx).Begin()，不能依赖GORM自动事务，因为跨分片事务本就不支持，得靠业务层兜底 - 别在model struct里嵌入
gorm.Model以外的字段来存DB引用——那会污染数据结构，也破坏GORM的零配置约定
ThreadLocal类机制在Go里不存在，别照搬Java那一套
看到Spring方案里大量提ThreadLocal和DynamicDataSourceContextHolder，千万别在Revel里尝试用sync.Map或全局map模拟。Go的goroutine不是线程，生命周期短且调度不可控，用map存DB映射极易造成内存泄漏或key冲突。
真正该用的是Revel原生的Controller.Params或http.Request.Context()——它们天然绑定单次HTTP请求生命周期，随请求创建，随响应销毁。所有路由状态都应该压在这两个地方，而不是自己造一套上下文管理。
最容易被忽略的一点：filter里设置的context必须通过c.Request = c.Request.WithContext(newCtx)重新赋值，否则下游中间件和controller方法拿到的还是原始context，DB就丢了。
