如何实现一个支持多租户的前端应用架构？

通过子域名、路径或登录后获取租户信息，建立全局租户上下文；2. 由后端返回品牌、功能配置动态渲染UI；3. 在请求拦截器中自动注入租户标识确保数据隔离；4. 采用单实例多租户或多实例部署结合微前端实现灵活扩展。

实现一个支持多租户的前端应用架构，核心在于隔离租户数据、动态配置界面，并确保系统可扩展和易于维护。关键不是让前端承担完整的租户逻辑，而是与后端协同，通过识别租户上下文来调整行为和展示。

1. 租户识别与上下文管理

前端需要在用户访问时确定当前所属租户，常见方式包括：

• 子域名识别：如 tenant1.app.com 和 tenant2.app.com，通过解析 window.location.host 获取租户标识
• 路径前缀识别：如 app.com/tenant1/dashboard，从路由中提取租户 slug
• 登录后获取租户信息：用户登录后，后端返回租户 ID 和配置，前端存入状态管理（如 Redux、Pinia）

一旦识别出租户，应建立全局的租户上下文，供后续请求、主题、菜单等模块使用。

2. 动态配置驱动UI

不同租户可能有不同的品牌、功能开关或菜单结构。前端应支持从后端拉取租户专属配置：

立即学习“前端免费学习笔记（深入）”；

• 加载租户的 品牌配置（如 logo、主色调、公司名称）并动态设置 CSS 变量或组件属性
• 根据租户的 权限和功能列表 渲染菜单和按钮，避免硬编码导航
• 使用配置中心返回 JSON Schema 或 UI 元数据，驱动表单、列表字段展示

这样无需为每个租户构建独立版本，一套代码即可适配多个客户。

3. 请求层注入租户信息

所有 API 请求需携带租户标识，通常通过拦截器自动注入：

• 在 HTTP 客户端（如 Axios 拦截器）中添加 Tenant-ID 请求头
• 或在查询参数中附加 tenantId（适用于不支持自定义 header 的场景）
• 确保敏感接口都依赖后端做租户数据隔离校验，前端仅做辅助

这保证了即使用户篡改前端逻辑，也无法越权访问其他租户数据。

4. 构建与部署策略

根据实际需求选择部署模型：

• 单实例多租户：所有租户共用同一套前端资源，通过运行时配置区分，适合标准化产品
• 多实例部署：为大客户单独部署前端实例，配合 CI/CD 动态替换配置文件（如 env.json），提供更高隔离性
• 使用 微前端架构 时，可按租户加载不同版本的子应用，实现更细粒度控制

基本上就这些。关键是把租户视为运行时上下文，而不是代码分支。通过统一的识别机制、配置驱动和请求注入，就能用一套前端支撑多个租户，同时保持灵活性和安全性。