Revel 框架通过拦截器在请求入口用子域名或 X-Tenant-ID 头识别租户，写入上下文；数据库层需显式传递 tenant_id（如 GORM Session 或 Repository 参数），禁止无条件查询；定时任务须按租户拆分并校验上下文；连接池、Redis、限流等基础设施必须按 tenant_id 隔离配置，否则数据或资源将串扰。
Revel 框架本身不内置多租户支持，但它的拦截器（Interceptor）、依赖注入（Injector）和请求上下文（revel.Controller）足够灵活，能支撑起一套轻量、可控的多租户 Web 架构。关键不是“Revel 能不能做”，而是你选哪一层做隔离、在哪一刻注入租户上下文、以及如何避免漏掉 tenant_id 过滤——这些地方一松动，数据就串了。
怎么在请求入口识别并绑定租户？
Revel 的 AppInit 阶段不处理具体请求，所以租户识别必须放在拦截器里。最稳妥的方式是用域名或请求头，而不是 URL path 或 query 参数——后者容易被伪造，也难做缓存和 CDN 分流。
- 推荐用子域名识别：比如
team-a.example.com→ 提取team-a作为tenant_id - 若必须用 header，统一约定
X-Tenant-ID，并在网关层（如 Nginx / API Gateway）校验其合法性，禁止客户端直传 - 千万别在 controller 里手动解析
req.URL.Query().Get("tenant")，这会绕过拦截器链，导致后续所有数据操作失去上下文 - 识别后立刻写入
revel.BEFORE拦截器的c.Params.Add("tenant_id", tenantID)，并同步设进自定义的TenantContext（用revel.Context的Set/Get方法）
怎么让数据库查询自动带上 tenant_id？
Revel 没有类似 Spring 的 @TenantFilter 或 MyBatis Interceptor，得靠 ORM 层自己兜底。如果你用的是 gorm（最常见），别指望全局 scope 自动生效——它只对 model 定义有效，对 raw SQL、关联预加载、事务内嵌套查询都不可靠。
- 所有
db.Where("tenant_id = ?", tenantID)必须显式写，不能省；db.First(&order)这类无条件查询在多租户系统里等于埋雷 - 把
tenant_id封装进每个 Repository 方法签名里，例如FindOrdersByStatus(tenantID string, status string)，强制调用方提供 - 如果用了 GORM v2，可配合
Session创建带默认 scope 的 db 实例：db.Session(&gorm.Session{Context: ctx}).Where("tenant_id = ?", tenantID)，但注意它不改变原始db实例，需显式传递 - 对复杂查询（如 JOIN 多张表），务必检查每张表是否都加了
tenant_id条件——漏一张，就可能查出其他租户的数据
怎么防止定时任务和后台 Job 跨租户执行？
Revel 的 Job 系统是全局单例，没有租户感知能力。一旦你注册一个 revel.Job{Func: syncOrders}，它就会无差别执行，根本不知道该为哪个租户跑。
- 所有定时任务必须拆成租户粒度：不是 “每天同步订单”，而是 “为 team-a 同步订单”、“为 team-b 同步订单” —— 用
tenant_id作为 job 名称或参数的一部分 - 用外部调度器（如 Quartz、Celery 或自研任务中心）替代 Revel 内置 Job，由调度器按租户维度分发；Revel 只暴露
/api/v1/tenant/:id/sync这类带租户路径的 endpoint 供触发 - 如果坚持用 Revel Job，必须在函数体内第一行就校验
tenant_id是否合法，且所有 DB 查询、Redis key、HTTP 调用都带租户上下文，否则一个任务崩掉，全租户受影响 - 特别注意：任务日志、错误上报、指标打点都要打上
tenant_id标签，否则出问题时根本分不清是哪个租户拖垮了队列
为什么配额控制必须在连接池和 Redis 层做？
Revel 控制不了数据库连接池大小、Redis 连接数、甚至 HTTP 请求并发上限——这些都在框架之外。等请求进到 Controller，资源已经被争抢过了。
- PostgreSQL 连接池（如 pgBouncer）要配置 per-tenant 最大连接数，靠
pool_mode=transaction+client_encoding或自定义变量识别租户，否则一个租户跑批处理会吃光所有连接 - Redis key 必须带前缀：
cache:team-a:order:123，而不是order:123；同时用redis.Config.PoolSize按租户分组初始化 client，避免连接复用污染 - HTTP 层限流（如基于 IP 或 token）不管用，得用租户 ID 做 rate limit key，例如
rate:team-a:api:/v1/orders，否则 A 租户刷接口，B 租户跟着 429 - 最关键的坑：Revel 的
revel.AppConfig.StringDefault("db.url", "")是全局配置，不能动态切租户数据源——你要么提前建好所有租户的*gorm.DB实例并缓存，要么用连接字符串模板 +tenant_id拼接后gorm.Open，但后者性能差、易泄漏连接
真正难的不是写几个拦截器或加几个 WHERE tenant_id = ?，而是整个系统里所有“隐式共享”的地方：连接池、线程池、缓存实例、日志采样率、Prometheus metrics label、甚至 Sentry 的 before_send hook——只要有一个没带上 tenant_id，隔离性就塌了一角。这不是 Revel 的缺陷，是所有单实例多租户系统的共性代价。
