⑴ 微前端——干坤qiankun Demo
微前端就是将不同的功能按照不同的维度拆分成多个子应用。通过主应用来加载这些子应用。微前端的核心在于拆，拆完后在合！
我们可以将一个应用划分成若干个子应用，将子应用打包成一个个的 lib 。当路径切换 时加载不同的子应用。这样每个子应用都是独立的，技术栈也不用做限制了！从而解决了前端协同开发问题。
文档地址： https://qiankun.umijs.org/zh
2018 年 Single-SPA 诞生了， single-spa 是一个用于前端微服务化的 JavaScript 前端解决方案 ( 本身没有处理样式隔离， js 执行隔离 ) 实现了路由劫持和应用加载。
2019 年 qiankun 基于 Single-SPA, 提供了更加开箱即用的 API （ single-spa + sandbox + import-html-entry ） 做到了，技术栈无关、并且接入简单（像 i frame 一样简单）。
这里我们打算建立三个项目进行实操，一个Vue项目充当主应用，另一个Vue和React应用充当子应用
基座：qiankun-base 子应用：qiankun-vue、qiankun-react
react + react-router 技术栈的主应用：只需要让子应用的 activeRule 包含主应用的这个路由即可。
vue + vue-router 技术栈的主应用:
用绝对路径，不用用相对路径，例如
qiankun 只能解决子项目之间的样式相互污染，不能解决子项目的样式污染主项目的样式
冲突的样式，采用BEM命名方式
子应用，需要增加 update 钩子以便主应用手动更新微应用
主应用，直接调用子应用实例的 update 方法即可
⑵ 微前端前言
微前端是一种多个团队通过独立发布功能的方式来共同构建现代化 web 应用的技术手段及方法策略。
主框架不限制接入应用的技术栈，微应用具备完全自主权
微应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新
在面对各种复杂场景时，我们通常很难对一个已经存在的系统做全量的技术栈升级或重构，而微前端是一种非常好的实施渐进式重构的手段和策略
每个微应用之间状态隔离，运行时状态不共享
微前端架构旨在解决单体应用在一个相对长的时间跨度下，由于参与的人员、团队的增多、变迁，从一个普通应用演变成一个巨石应用后，随之而来的应用不可维护的问题。这类问题在企业级 Web 应用中尤其常见。
1.url 不同步。浏览器刷新 iframe url 状态丢失、后退前进按钮无法使用。
2.UI 不同步，DOM 结构不共享。想象一下屏幕右下角 1/4 的 iframe 里来一个带遮罩层的弹框，同时我们要求这个弹框要浏览器居中显示，还要浏览器 resize 时自动居中。
3.全局上下文完全隔离，内存变量不共享。iframe 内外系统的通信、数据同步等需求，主应用的 cookie 要透传到根域名都不同的子应用中实现免登效果。
4.慢。每次子应用进入都是一次浏览器上下文重建、资源重新加载的过程。
通过监听 url change 事件，在路由变化时匹配到渲染的子应用并进行渲染，这个思路也是目前实现微前端的主流方式。同时single-spa要求子应用修改渲染逻辑并暴露出三个方法：bootstrap、mount、unmount，分别对应初始化、渲染和卸载，这也导致子应用需要对入口文件进行修改。过于基础，成本太高，不建议。
qiankun是阿里推出的一个基于single-spa的微前端实现库，旨在帮助大家能更简单、无痛的构建一个生产可用微前端架构系统。因为是基于single-spa进行封装，所以single-spa的特点也被qiankun继承下来。成本低于single-spa，高于MicroApp。
MicroApp是京东推出的一款基于类WebComponent进行渲染的微前端框架，不同于目前流行的开源框架，它从组件化的思维实现微前端，旨在降低上手难度、提升工作效率。它是目前市面上接入微前端成本最低的框架，并且提供了JS沙箱、样式隔离、元素隔离、预加载、资源地址补全、插件系统、数据通信等一系列完善的功能。是目前市面上接入微前端成本最低的方案。
single-spa github地址： https://github.com/single-spa/single-spa
qiankun官网： https://qiankun.umijs.org/zh
MicroApp官网： https://cang.org/micro-app/
⑶ 微前端——Single-SPA（二）
1、新建一个html
2、新建一个single-spa-config.js
3、改造React入口文件
如此就完成了一个最基础的例子
核心理念其实就是修改了react渲染的方式，采用了singleSpaReact去渲染，而后通过父项目中匹配路径去挂载和卸载子模块
⑷ 前端微服务设计
近些年，前端发展呈百家争鸣式发展，框架层出不穷，版本更是迭代不穷，难免会出现前端项目技术栈不统一、所用框架版本不统一的情况。
如若某些项目，没有新的功能加入，又能线上稳定运行，但其技术栈却用的是 vue1.0，为了将其结合到新应用中去而对其重构，成本会很高。然而，微服务可以帮我们解决这个问题。
在既不重写原有系统的基础之下，又可以抽出人力来开发新的业务。其不仅仅对于业务人员来说是一个相当吸引力的特性，对于技术人员来说，不重写旧的业务，能在一些新技术上做挑战，也是一件很有意思的事情。
除此之外，在这两三年里，移动应用出现了一种趋势，用户不想装那么多应用。而往往一家大的商业公司，会提供一系列的应用。这些应用也从某种程度上，反应了这家公司的组织架构。然而，在用户的眼里他们就是一家公司，他们就只应该有一个产品。相似的，这种趋势也在桌面 Web 出现。聚合成为了一个技术趋势，体现在前端的聚合就是微服务化架构。
理想的前端微服务化，应该是符合如下几个特点：
路由分发式微前端，即通过设置路由，将不同的业务分发到不同的、独立前端应用上。其通常可以通过 HTTP 服务器的反向代理来实现，又或者是应用框架自带的路由来解决。
就当前而言，通过路由分发式的微前端架构应该是采用最多、最易采用的 “微前端” 方案。但是这种方式看上去更像是多个前端应用的聚合，即我们只是将这些不同的前端应用拼凑到一起，使他们看起来像是一个完整的整体。但是，它们并不是一个完整的整体，每次用户从 A 应用到 B 应用的时候，往往需要刷新一下页面。
通常可通过 nginx 配置反向代理，来进行路由分发，从而实现前端微服务。
它适用于以下场景：
iframe 可以创建一个全新的独立的宿主环境，这意味着我们的前端应用之间可以相互独立运行。
采用 iframe 有几个重要的前提：
即何时加载、卸载应用，如何监听应用事件等。
不论是基于 Web Components 的 Angular，或者是 VirtualDOM 的 React 等，现有的前端框架都离不开基本的 HTML 元素 DOM。
那么，我们只需要：
第一个问题，创建 DOM 是一个容易解决的问题。而第二个问题，则一点儿不容易，特别是移除 DOM 和相应应用的监听。当我们拥有一个不同的技术栈时，我们就需要有针对性设计出一套这样的逻辑。现有的框架有single-spa、qiankun、mooa等
常见的方式有：
其次，采用这种方式还有一个限制，那就是：规范！ 规范！ 规范！。在采用这种方案时，我们需要：
Web Components 组件可以拥有自己独立的 Scripts 和 Styles，以及对应的用于单独部署组件的域名。然而它并没有想象中的那么美好，要直接使用纯 Web Components 来构建前端应用的难度有：
现有的微前端框架有single-spa、qiankun、mooa。其均是在前端框架之上设计通讯、加载机制来实现的。
⑸ 前端布局的几种方式
1.固定布局，静态布局
传统Web设计，网页上的所有元素的尺寸一律使用px作为单位，网页宽度一般为960px。网页布局始终按照最初写代码时的布局来显示，不受浏览器影响。如果浏览器宽度如果小于这个宽度就会出现滚动条，如果大于这个宽度则内容居中外加背景
2.流式布局
流式布局使用的是百分比，这位网页提供了很强的可塑性和流动性，与固定宽度布局基本不同点 就在于对网站尺寸的侧量单位不同。屏幕分辨率变化时，页面里元素的大小会变化而但布局不变，这可能导致如果屏幕太大或者太小都会导致元素无法正常显示。
3.自适应布局
自适应布局的特点是分别为不同的屏幕分辨率定义布局，即创建多个静态布局，每个静态布局对应一个屏幕分辨率范围。使用 @media 媒体查询给不同尺寸和介质的设备切换不同的样式，例如宽度960px是一种样式，网页宽度1440px是另一种样式。改变屏幕分辨率可以切换不同的静态局部，但在每个静态布局中，页面元素不随窗口大小的调整发生变化。
4.弹性布局
使用em 或 rem 单位进行相对布局，相对%百分比更加灵活，同时可以支持浏览器的字体大小调整和缩放等的正常显示。这种布局中包裹文字的各元素的尺寸采用em/rem做单位，而页面的主要划分区域的尺寸仍使用百分数或px做单位。默认的文字大小16px就是1em。
5.响应式布局
每个屏幕分辨率下面会有一个布局样式，即元素位置和大小都会变，设计方法通常采用了媒体查询+流式布局，使用@media媒体查询给不同尺寸和介质的设备切换不同的样式。为不同终端的用户提供更加舒适的界面和更好的用户体验。
⑹ 微前端qiankun
微前端qiankun 使用，一些注意事项。附上 qiankun官网
主应用(vue)
1、安装qiankun
2、修改 main.js
主应用到这就可以了，下面的是一些扩展加载微应用事项
3、router页面配置加载微应用
修改主应用router.js
在About.vue文件中加入
4、如果在vue-admin模板中使用干坤，需要注意的是：
<div id="container"></div> 不能写在页面中，只能写在Appmain.vue 中，
路由需要配置重定向
判断改变路由（这里可写配置文件，偷懒就写死了）
AppMain.vue,需要判断显示的是哪个微应用，改变其id显示
微应用（vue）
1、在 src 目录新增 public-path.js：
2、 main.js 修改。
3、打包配置修改（vue.config.js）：
微应用（react）
1、在 src 目录新增 public-path.js：
2、设置 history 模式路由的 base：
3、 index.js 修改
4、webpack 配置
安装插件 @rescripts/cli。
根目录新增 .rescriptsrc.js：
修改 package.json：
⑺ 前端几种常见的布局方式
1.静态布局（固定宽高）
2.弹性布局（flex）————常用
3.圣杯布局
flex：flex-group、flex-shrink、flex-basis
flex：auto/none/负数/一个长度或百分比/两个非负数/一个非负数和一个长度或百分比等
A，flex-group：当父元素有剩余空间时，子元素占据剩余空间的量
B，flex-shrink：当父元素的空间不足以展示所有的子元素，父元素没设置flex-wrap，子元素需要进行收缩的量
C，flex-basis：表示该子元素的初始宽度
4.自适应布局（为不同的屏幕分辨率定义的布局 @media媒体查询技术）
5.流式布局：（宽高用百分比，按屏幕分辨率调整，布局不发生变化）
6.响应式布局（使用meta标签，宽高随窗口调整自动适配，适应布局和流式布局的综合方式）
7.栅格布局
1）.栅格(网格划分)：在一个特定区域内划分出有规律的格子，依靠这些格子进行有规律的版面布局。
使用栅格布局：bootstrap（12列），element（24栏），antDesign
2）.栅格布局
container：栅格系统容器；rows：行；cols：列；gutters：各列间的空隙
3）.栅格布局实现响应式布局
8.table布局（使用表格进行页面排版和样式设置）
1）.用法
display:table
display:table-cell，相当于td元素
display:table-row，相当于tr元素
table-layout:fixed | auto(默认)：table-layout 属性用于显示表格单元格、行、列；auto, 自动表格布局，列的宽度由单元格中最大内容的宽度决 定；fixed ,固定表格布局。
⑻ 快速上手微前端框架 icestark （一）
微前端本质和后端微服务理念是一样的，微前端解决方案一般包含如下特点
初始化 Vue 主应用
初始化 React 主应用
本地实例初始化的 Vue 主应用，运行如下
本地地址： http://localhost:3000
本地运行的官方主应用Demo,已经整合了官方提供的 Vue,React 子应用，接下来本地创建子应用，运行后分别挂在到本地启动的主应用中
Vue 子应用
本地地址： http://localhost:3001
React 子应用
本地地址： http://localhost:3333
在主应用中注册子应用，在主应用 App.vue 中的 onMounted 中修改 ice 注册配置，修改 name, activePath, title, entry 这四个属性即可
注意 activePath 指向子应用中的路由地址， entry 地址这里使用子应用启动后的根路由地址, 也可以指向对应的子应用指定地址, 如 http://localhost:3333/react
在主应用的 BasicLayout.vue 文件中配置 el-sub-menu
单独配置子应用路由对应主应用中的 activePath ，实现正常加载
React 子应用路由， 配置了一个 /react 路由地址
Vue 子应用路由, 配置一个 /vue 路由地址
这时候主应用的侧边栏的内容对应到本地启动的子应用，并且能访问就整合成功了，这时候已经本地示例实现了 icestark 框架的应用整合，应用接入，路由配置跳转的能力。
接下来，将在本地示例中实现子应用间的路由切换（页面跳转）和应用互相通信。
⑼ 轻量、高效、功能强大的微前端框架-MicroApp
这几年后端的微服务是比较火爆，我们公司目前只要是新项目，基本上都是基于微服务去架构的，那么微前端是什么呢？
微前端是借鉴了微服务的架构理念，核心在于将一个庞大的前端应用拆分成多个独立灵活的小型应用，每个应用都可以独立开发、独立运行、独立部署，再将这些小型应用融合为一个完整的应用，或者将原本运行已久、没有关联的几个应用融合为一个应用。微前端既可以将多个项目融合为一，又可以减少项目之间的耦合，提升项目扩展性，相比一整块的前端仓库，微前端架构下的前端仓库倾向于更小更灵活
以前我们为了把几个独立运行的小型应用合并成一个应用都是通过iframe的方式去实现的，如果不考虑体验问题，iframe 几乎是最完美的微前端解决方案了。
iframe 最大的特性就是提供了浏览器原生的硬隔离方案，不论是样式隔离、js 隔离这类问题统统都能被完美解决。但他的最大问题也在于他的隔离性无法被突破，导致应用间上下文无法被共享，随之带来的开发体验、产品体验的问题
micro-app不是基于iframe架构的
micro-app提供了js沙箱、样式隔离、元素隔离、预加载、数据通信、静态资源补全等一系列完善的开箱即用功能
micro-app没有任何依赖
为了保证各个业务之间独立开发、独立部署的能力，micro-app做了诸多兼容，在任何技术框架中都可以正常运行。
下面我讲一下如何在Vue中使用micro-app
1、初始化一个基座应用
2、基座应用的文件修改
main.js修改
router.js修改
3、main-page.vue页面
4、创建一个子应用
5、子应用的router.js文件修改
6、src目录下新建 public-path.js
7、 main.js 引入public-path.js
到此这个简单的微应用就搭好了
觉得效果不错的请帮忙加个关注点个赞，经常分享前端实用开发技巧
⑽ qiankun微前端框架处理
https://blog.csdn.net/qq_41694291/article/details/113842872
概念：微前端的概念借鉴于后端的微服务，一般以业务功能为拆分单元
解决问题：大型项目的变更、扩展、维护困难的问题
总体积变大，插件可上传cdn，但公共函数资源不便于共享
iframe ：隔离性和兼容性好，性能和使用感差（性能差因为不会有缓存，每次重新加载）
基座模式 ：基于 路由分发 ，由基座监听路由变化，加载不同的应用，实现应用解耦，single-spa、qiankun
组合式集成 ：组件单独打包发布，类似于npm包
EMP ：主要基于Webpack5 Mole Federation
web components ：
我们采用的是qiankun，主要思路是将一个大应用，拆分为更小的、可独立开发、测试、部署的子应用。
传统的大型项目：所有模块都在一个应用里，由应用本身负责路由管理，属于 应用分发路由 方式
拆分微应用的项目：属于基座模式下的系统架构，各应用互相独立，单独运行在不同的服务上，基座（基座一般是用户最终访问的应用）根据路由去加载不同的应用到页面上，即 路由分发应用 方式
微前段主要需要解决的问题有两个
qiankun和single-spa对比
activePath与当前的hash对比一致