这篇文章将为大家详细讲解有关怎么接地气地接入微前端，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。
成都创新互联坚持“要么做到，要么别承诺”的工作理念，服务领域包括：网站建设、网站制作、企业官网、英文网站、手机端网站、网站推广等服务，满足客户于互联网时代的锦屏网站设计、移动媒体设计的需求，帮助企业找到有效的互联网解决方案。努力成为您成熟可靠的网络建设合作伙伴！
一 前言
微前端，这个概念已经在国内不止一次的登上各大热门话题，它所解决的问题也很明显，这几个微前端所提到的痛点在我们团队所维护的项目中也是非常凸显。
但我始终认为，一个新的技术、浪潮，每每被讨论最热门的一定是他背后所代表的杰出思考。
"微前端就是...xx 框架，xx 技术"
这种话就有点把这种杰出的思路说的局限了，我只能认为他是外行人，来蹭这个词的热度。
在我所负责的项目和团队中，已经有非常大的存量技术栈和页面已经在线上运行，任何迭代升级都必须要保证小心翼翼，万无一失。
可以说，从一定程度来讲，微前端所带来的这些好处是从用户体验和技术维护方面的，对业务的价值并不能量化体现，落地这项技术秉着既要也要还要的指导方针。
我们对存量技术栈一定需要保持敬畏，隔离，影响范围可控的几个基本要素，然后再考虑落地实施微前端方案。
所以，在这个基本要素和指导方针下，要落地这项新的技术，一定要充分了解当前改造站点所存在的技术方案、占比以及当前成熟的微前端框架已提供的能力差异，切勿生搬硬套。
二 背景
我所在团队维护的项目都是些 PC 操作后台（Workstation），这些工作台会存在不同的国家，不同时区，不同合作方等等问题。
如果需要开发一个新的页面需求，很可能投入进来的开发人员都来自不同团队，此时我们要在完成现有需求的同时还需要保证多个管理页面的风格统一，设计规范统一，组件统一，交互行为统一这非常困难。
当该业务需要迁移到另外一个工作台时，虽然需要保持逻辑一致，但导航栏、主题等却不同。
当前存量的方案都是采用 Java 直接进行 Template 渲染出 HTML，经过前面几代前辈的迭代，不同系统中已经存在几种不同技术栈产出的页面。
虽然都是 React 来实现的，但是前辈们都非常能折腾，没有一个是按照常规 React 组件形式开发出来的。
比如：
大部分页面是通过一份 JSON 配置，消费组件生成的页面。
部分页面是通过另外一个团队定义的 JSON 配置消费组件生成的，与上面 JSON 完全不一样。
还有一部分页面，是通过一套页面发布平台提供的 JS Bundle 加载出来的。
面对这样的技术背景下，除了微笑的喊 MMP，含泪说着自己听不懂的话（存在即合理，不难要你干嘛？），还得接地气地出这样一个落地方案。
三 方案 & 流程图
首先，需要明确的分析出站点所有页面，所需要加载的通用特性：
上述是精简过后的一些通用功能特性，这里简单做下介绍：
Layout Loader：用于加载不同工作台的导航
DADA Loader：用于加载 JSON 配置的页面
Source Code Loader：用于加载 JS Bundle
Micro Loader：用于处理微前端加载
Log Report：用于日志埋点
Time Zone：用于切换时区
i18n：用于切换多语言
Guider：用于统一管控用户引导
除此以外可能还会存在以下这些页面扩展能力：
粗略统一归类后来看，页面的大体加载流程应该是这样：
四 实现细则
基于上述一个加载思路，首先需要做的是页面加载路径收口，需要保证所有页面的加载入口是在一个统一的 Loader 下，然后才可以较为系统的处理所有页面的加载生命周期。
在收敛的同时，同样需要保持开放，对核心加载路径要保持插件化开放，随时支持不同的扩展能力，渲染技术栈接入。
1 插件机制
所以，在主路径上，通过 Loader 加载配置进行处理，这份配置在主路径中提供上下文，然后交由插件进行消费，如图所示：
举个例子，拿一个独立的 JS Bundle 类型的子应用来说：
