很多团队第一次做 Next.js 多租户时，最先想到的是路由怎么区分租户。
这当然是问题的一部分，但远远不够。真正复杂的地方往往在于：
- 域名和租户如何映射
- 配置和主题如何按租户加载
- 数据与缓存如何隔离
- 一个租户出问题时会不会波及其他租户
所以多租户架构设计的核心，不是“怎么识别租户”，而是“怎么把租户边界做稳”。
先分清多租户的三类隔离需求
多租户架构至少涉及三层隔离：
- 展示隔离：域名、品牌、主题、导航
- 数据隔离：数据库、缓存、文件资源、搜索索引
- 运行隔离：部署单元、限流、故障影响范围
如果只做展示层识别，而忽略后两层，系统在租户规模扩大后会迅速暴露风险。
域名映射只是入口，配置加载才是关键
Next.js 多租户通常会走这几种入口模式：
- 子域名
- 自定义绑定域名
- 路径前缀
无论哪种模式，最终都要解决一个更核心的问题：请求进来之后，系统如何快速、稳定地拿到当前租户配置。
这通常意味着需要一层租户解析与配置缓存，而不是每次请求都重新散查。
缓存策略必须把“公共缓存”和“租户缓存”分开
多租户系统最危险的一类问题，就是缓存串租。
常见原因包括：
- CDN key 设计不完整
- 页面缓存没带租户标识
- 接口层使用了过于粗糙的全局缓存
如果这一层没做好，最严重的结果不是页面慢，而是把 A 租户的数据给了 B 租户。
模板复用与租户定制要有边界
多租户系统很容易在复用和定制之间走向两个极端：
- 太强调统一，租户个性化能力不足
- 太强调定制，最终变成“一租户一套系统”
更现实的方式通常是分层：
- 核心框架、布局和组件保持统一
- 主题、模块开关、内容区块允许受控配置
- 少数强定制能力通过扩展点处理
这样既能保持维护效率，也能给业务足够灵活性。
一个常见失败案例：租户数增加后，部署和缓存复杂度同步爆炸
这类问题通常说明系统前期只关注了路由识别，没有把缓存、配置和隔离策略一起设计。
结果就是：
- 新租户接入越来越慢
- 每次发布都担心影响所有租户
- 缓存规则越来越多却越来越不可信
多租户不是在单租户应用外面套一层判断，而是要把边界作为基础能力内建进去。
一份可直接复用的检查清单
- 是否分别设计了展示、数据和运行三层租户隔离
- 域名解析后是否有稳定的租户配置加载机制
- 缓存 key 是否明确包含租户边界
- 模板复用与定制是否有清晰分层
- 部署、监控和故障隔离是否支持租户维度治理
总结
Next.js 多租户架构设计的关键，不是把租户识别出来，而是把租户边界做成系统能力。只要先把配置加载、缓存隔离和模板分层守住，多租户系统才能在规模扩大后保持可控。
进一步阅读：
