域名驱动多租户入驻：后台配置 + 前端解析

摘要线上租户以访问域名为准，机构与域名的绑定在后台维护；前端在启动阶段用当前域名请求 getByDomain 解析机构信息等，写入会话并在后续请求携带机构信息。话说回来，src/tenant 与建立变量承担可选白标定制。与域名租户上下文分层，不宜混写成「一租户一建立产物」。

一、先分清两件事

多租户常被说成「一套代码服务很多家机构」。在本项目里建议拆成两层理解：

二、使用者痛点聚焦：为何多租户看似简单却容易失控？

• 痛点①：数据隔离不彻底导致跨租户泄漏。 如果后端接口未严格按 orgCode 筛选，错误的数据可能会被错误的租户看到。老实说，
• 痛点②：前端路由或主题误配导致品牌混乱。 不同租户需要不同的 logo、协议页和权限控制，一旦方法冲突就会出现 UI 混杂或功能缺失。
• 痛点③：部署流程繁琐，易出错。 每新增一个租户都需要手工创建目录、复制模板和更新映射表，一旦遗漏就会导致无法访问或错误提示。
• 痛点④：开发环境难以复现生产场景。说起来， 模拟多域名时容易忘记同步 /etc/hosts。或者未把 .env.local.VITE_APP_DOMAIN; 这会让调试变得极其困难，
• 痛点⑤：监控与日志难以按租户区分。 若请求头中没有统一的 x-app-id 。后台日志无法直接归类到对应 tenant，从而影响运维排查效率。不过，
• *解决思路*: 在代码层面严格把握“谁配置”“如何读取”三大环节。并通过自动化脚本减少人工操作；提供统一日志标准和监控告警，让运维能快速定位问题。

*小结*这方面，以上痛点是多租户实现过程中最常见且致命的陷阱。方法主要是“**先分清概念** + **自动化流程** + **统一上下文**”。下面给出具体实现细节，

三、运行时主链路：域名 → 机构 → 请求头

用域名换机构

生产环境请使用真实 hostname；可通过 VITE_APP_DOMAIN 或 hosts 文件模拟。

export function getShopInfo{
return request({
从url来看，'/getByDomain',method:'get'。params:{hostname : window.location.hostname}
})
}

• - 本地调试请确保 VITE_APP_DOMAIN 与测试环境一致，否则返回值为空。
• - 后台负责维护映射表，避免硬编码造成版本漂移。
• - 接口命名保持 “半登录”，兼容无登录站点场景。

路由守卫里初始化店铺与 orgCode

应用启动后注册全局 beforeEach 守卫，用 await ensureShopInfo 拉取店铺信息；成功后写入 sessionStorage 并更新 Pinia store。

try{
shopStore.setLoading;说起来，const shopRes = await getShopInfo;if{
sessionStorage.setItem,shopRes.data);let shopInfo = {...shopRes.data};shopStore.setShopInfo;}
}