大型前端应用如何做系统融合？
内容提要
该文章介绍了A平台和B平台的融合优化方案，通过部署优化、代码仓库整合、项目框架、系统权限等措施实现了两个平台的融合。同时，还设计了目录结构、应用类型判断、路由设计、环境变量设计、请求设计、权限和登录、公共函数设计、脚手架配置设计、Vuex store设计和页面引用设计等方案。最终，通过这一融合过程提升了用户体验和组件复用率。
延伸解读
融合的核心思路：域名识别与内容隔离
文章提出的融合方案并非将两个平台合并为单一入口，而是让用户继续使用各自域名访问，前端通过维护域名映射表自动识别当前应用类型，再加载对应的路由、环境变量和登录逻辑。这种设计保证了融合前后用户查看的内容一致，同时避免了因入口变更带来的体验波动。对于需要整合多个独立前端项目的团队，这种“同代码库、多环境识别”的思路值得参考。
目录结构与请求封装的分层策略
方案将差异较大的文件按应用拆分为独立文件夹，再通过统一的index文件根据运行环境加载对应内容；差异较小的文件则直接融合并手动解决冲突。请求层采用基础封装加业务封装的模式，先封装公共的createHttp，再为每个业务单独处理header、code码等差异。这种分层方式降低了融合复杂度，也便于后续新增应用时按同样模式扩展。
融合带来的实际收益与代价
文章提到融合后跳转单个页面的白屏时间从约2998ms降至约800ms，组件复用率也得到提升。收益主要来自部署优化、代码仓库整合以及页面引用方式的改变——原先通过iframe嵌套的B应用页面，融合后可直接引入组件，后端数据也随之打通。但整个过程耗时两个月，涉及路由、权限、Vuex store等多处改造，说明融合并非简单的代码合并，而是需要系统性的架构调整。
权限与登录的多套逻辑维护
由于A应用和B应用原本使用不同的服务端接口和登录体系，融合后前端需要根据应用类型字段识别不同环境，并维护多套登录处理逻辑。这意味着融合并没有统一后端权限模型，而是在前端层面做了适配。对于计划做类似融合的团队，需要评估这种多套逻辑长期维护的成本，以及是否具备逐步统一后端权限体系的条件。
Q&A
A平台和B平台的主要功能是什么？
A平台提供注册入驻服务，B平台专注于具体业务操作服务。
如何通过系统融合提升用户体验？
通过优化部署、代码整合和架构设计，减少页面加载时间，提升用户体验。
在融合过程中如何处理代码仓库？
A应用与B应用的代码仓库整合，确保分离过程不影响现有配置。
目录结构设计在融合中有什么作用？
目录结构设计防止文件冲突，减少融合复杂度，确保系统正常运行。
如何实现不同环境的应用类型判断？
通过维护域名映射表，前端根据不同域名识别应用类型。
融合后如何处理权限和登录逻辑？
根据应用类型字段识别不同环境，维护多套登录逻辑以适应不同应用。
