Revel 中实现多租户需三步：启动时在 app/init.go 初始化多个独立 *gorm.DB 实例（如 DBMaster、DBShard1），通过 BEFORE Filter 从 Host 或请求头识别租户 ID 并注入上下文，模型层按需获取对应 DB 实例执行操作，严禁复用全局 DB 或依赖 Scopes 切换连接。
Revel 框架本身不内置多租户支持，但可通过“连接预置 + 请求上下文注入 + 模型层适配”三步落地，关键在于避免修改全局 gorm.DB 实例，改用按请求绑定的分库实例。
如何在 Revel 中初始化多个数据库连接
GORM v2+ 自动管理连接池，无需手动封装 sql.DB。在 app/init.go 的 Init() 函数中声明并初始化多个 *gorm.DB 变量：
-
DBMaster用于管理租户元数据（如租户配置、子域名映射） -
DBShard1、DBShard2等对应具体租户的业务库（可按子域名、X-Tenant-ID或 JWT 解析结果动态选择） - 每个连接应使用独立的 DSN，并显式调用
db.SetMaxOpenConns()和db.SetMaxIdleConns()避免连接耗尽
注意：不要复用同一个 *gorm.DB 实例跨租户写入，否则会因连接池混用导致事务/上下文污染。
怎样从 Host 头或请求头识别租户
Revel 的 Filter 是最自然的拦截点。推荐在 BEFORE 阶段解析 Host 头提取子域名（如 team1.example.com → team1），或读取 X-Tenant-ID 头：
- 若用子域名，需提前在 DNS 或反向代理层确保所有租户子域指向同一应用实例
- 若用
X-Tenant-ID，前端必须在每次请求中携带该头，适合 API 场景 - JWT 方式需在 Filter 中解码 token 并校验
tenant_id声明，注意密钥同步和过期处理
识别出的租户标识应存入 revel.Request.Params 或自定义上下文字段（如 c.Params.Set("tenant_id", tid)），供后续 filter 和 controller 使用。
如何让模型访问对应租户的 DB 实例
不能让模型直接引用全局 DBMaster 或硬编码某个分库。正确做法是：在 filter 中根据租户 ID 查找已初始化的 *gorm.DB 实例，并将其注入当前请求上下文：
- 维护一个租户 ID 到
*gorm.DB的映射（如map[string]*gorm.DB），启动时加载租户配置表填充 - 在 filter 中调用
c.Params.Set("tenant_db", db)，controller 再通过c.Params.Get("tenant_db")获取 - 模型方法接收
*gorm.DB作为参数（例如User.FindByID(db, id)），而非依赖全局变量
这样既避免了 GORM 全局单例被覆盖的风险，又保持了模型逻辑的可测试性——单元测试时可传入 mock DB 实例。
为什么不能用 GORM 的 Session 或 Scopes 实现租户隔离
Session 和 Scopes 仅适用于共享数据库 + tenant_id 字段的行级隔离模式，而 Revel + GORM 多租户常见于物理分库场景（如每个租户独立 MySQL 实例）。此时：
-
Scopes无法切换底层连接，只能追加 WHERE 条件，对错库查询无防护 -
Session的WithContext仅影响事务和日志，不改变连接目标 - 若强行用
tenant_id字段隔离，需在每张表加该字段，并为所有查询自动注入 scope，但一旦漏掉就可能跨租户读写
物理分库虽运维成本高，但在 Revel 这类无 DI 容器的框架里反而更可控——连接错误会在启动或首次查询时暴露，而不是在生产环境静默泄露数据。
