怡宁 SaaS 互联网智慧医院管理系统
让不同医院在统一平台管理线上患者、医生、销售与财务业务。
先明确项目为何存在。
从业务目标进入技术问题，让后续架构选择拥有可判断的上下文。
概览
连接线下医院的互联网问诊、开方、销售、随访、对账和医生管理等业务，为不同医院提供统一的线上运营后台。
问题
多医院共用一套后台时，Vuex 与本地缓存未按租户隔离，可能出现其他医院列表或 IM 会话混入当前上下文。
真正需要被拆解的约束。
- 01
在统一系统中隔离不同医院的业务数据与会话状态。
- 02
连接患者、医生、处方、销售、随访和财务流程。
- 03
维护线上系统稳定性并持续处理接口联调问题。
让数据、状态与交付边界可解释。
以 hospitalId 作为租户上下文贯穿请求、状态仓库和本地缓存，在共用后台内划清医院数据与会话边界。
- 01租户上下文
用户选择医院后建立当前 hospitalId 与权限范围。
- 02请求与 Store
所有业务请求和 Vuex 状态统一携带租户标识。
- 03缓存与 IM 隔离
本地数据按租户分桶，切换医院时清理列表与会话。
- 04医疗业务模块
承载问诊、开方、销售、随访、对账和医生管理。
把工程决策和交付结果放在一起验证。
- 01
在请求和 Store 中统一携带 hospitalId。
- 02
将本地缓存按租户分桶，并在医院切换时清理会话与列表状态。
- 03
基于 PigX、Vue 2 与环信 IM 复用通用管理能力。
- 01
交付多医院共用的互联网智慧医院管理后台。
- 02
覆盖问诊、开方、销售、随访、对账和医生管理流程。
- 03
收敛多租户状态边界，降低医院切换时的数据串扰风险。
性能首先是一组工程约束。
只记录项目中真实采用的策略，不用无法核验的数字替代判断。
优化目标多租户切换时的数据正确性与冗余状态清理。
- 01
缓存键统一纳入 hospitalId，避免读取到其他医院的历史数据。
- 02
切换租户时主动释放列表和 IM 会话状态，控制过期数据驻留。
- 03
复用 PigX 通用管理能力，将开发资源集中在医疗业务流程。
沉淀可以迁移到下一次决策的经验。
多租户隔离应成为请求、状态与缓存共同遵守的系统约束。
反思 01
数据正确性属于性能体验的一部分；快速显示错误租户数据并不是有效优化。
反思 02
从技术栈回到可验证的能力。
技术栈
关联能力