Ⅰ 微前端 quankun + vue
1、安装 qiankun
2、在主应用中注册微应用
1、main.js 导出相应的生命周期钩子
2、vue.config.js 配置微应用的打包工具
Ⅱ 为什么前端用vue的公司越来越多
1、对于创业公司一般起步的产品都是信息类（比如知乎、微博、商城类，并没有太多对底层硬件的依赖的应用）的ios+安卓客户。
用vue类的框架可以做出spa页面，然后只需要套壳就可以生成ios/安卓客户端，同时只需要维护一套代码即可，大大缩短了上线时间，对于创业公司可谓下对了药，要知道创业初期老板最着急上线的。
2、weex to native对于已经有成熟的互联网公司，他们更看重的是用户体验，自然对产品的流畅程度有了更高的要求，套壳应用的性能受所在手机的浏览器性能的影响。
在复杂操作的页面自然不能和原生比，好消息是随着前端技术的不断探索，借助node.js前端们可以让js生成ios/安卓的代码，比如阿里的weex，fb的react-native都可以直接用原生js的语法生成原生应用，这里的weex就是淘宝用vue的api设计的。
3、微信小程序还有最近火的微信小程序，其代码就是JS。微信小程序的API也是按照Vue来设计的，也就是学会了Vue，学weex和小程序就会非常快。之所以这两者在用Vue的API也正是因为Vue设计的API比较易懂上手快。
(2)vue微前端技术选型外包扩展阅读：
Vue.js的目标是通过最简单的API实现相应的数据绑定和组合的视图组件。
它不仅易于上手，而且还便于与第三方库或既有项目整合。另一方面，当与单文件组件和Vue生态系统支持的库结合使用时，Vue也完全能够为复杂的单页应用程序提供驱动。
Vue.js自身不是一个全能框架——它只聚焦于视图层。因此它非常容易学习，非常容易与其它库或已有项目整合。另一方面，在与相关工具和支持库一起使用时，Vue.js也能完美地驱动复杂的单页应用。
Ⅲ qianKun + VUE 实现微前端架构 (基于vue2实现)
创建两个项目作为实现demo，一个为主应用，一个为子应用
3.配置函数文件 microAppSetting
4.微应用出口文件 index.js
5.在App.vue内配置微应用容器及跳转菜单
6.在main.js文件内引入微应用出口文件 index.js
7.运行后展示
8.在配置完子应用后的主应用展示
点击子应用菜单
1.修改子应用路由文件内路由实例属性： base 为 "/child"
2.在main.js文件内导出生命周期钩子
3.配置Webpack、跨域与端口号
在vue.config.js内添加：
4.运行后展示
package.json
Ⅳ 电商后台管理系统的前端技术栈-----vue
现在市面上流行的框架有Jquery，Angular,Vue,React，下面说一下为什么vue胜出了。
1.首先上场的是陪伴了我们N多多多年的jq大哥，他是原生js的封装，帮助我们快速操作Dom，vue和react则是颠覆了操作dom的思想，通过数据的双向绑定更改数据；
2.jq更偏向于js操作样式，而vue和react这是进行数据操作较多一些；
3.在我们的项目中选用了vue，因为公司前端人员都会vue，不再需要学习成本，并且vue适合各种大小的项目，react更偏向于大型的项目；
4.在搭建后台管理系统上，大家都明白的基本上是不需要太多ui图的，我们采用了ui库（iview），这个iview是跟element对比后，做出的选择，因为iview的功能更全，组件ui样式更多一些；
5.项目的搭建没有采用vue-cli，我认为vue-cli是为了模块化，现在我们使用了iview这个ui组件库，就没有必要封装自己的组件了。所以我们采用了多页面的vue；
6.项目在css上选择less，后期的打包还是使用webpack的，后期会出一篇文章讲解webpack的多页面打包。
总结：如果我的方向哪里有错误的地方，还希望多多指教。
Ⅳ qiankun 实战（一）
前两天用了一下微前端框架 icestark , 在实际架构搭建过程中发现中发现在 Vue 主应用子应用之间切换 tag （tag 分别主应用和子应用的页面）页签时会有子应用数据状态无法保存的情况，搜索了一波解决方案后发现， icestark 中 React 应用实现了对数据状态的缓存， Vue 里面没有这个实现。
React 实现的思路是通过 Tabs 组件结合 icestark 实现的一种机制，但是没有用到路由。由于架构时间有限，发现按照那个方案调整是实现方面时间代价有点大，尝试了一下 qiankun 发现框架中可以不存在这个问题，所以决定更换微前端框架方案为 qianun 。
如果想了解 icestark 可以看如下文章, 里面有一些关于微前端架构理念的思考
快速上手微前端框架 icestark （一）
快速上手微前端框架 icestark （二）
本地使用 vue-cli 创建了一个 Vue2.0 纯净项目作为主应用，执行 yarn add qiankun 命名安装 qiankun ，在 main.js 中引入 qiankun , 注册并启动
安装 vue-router 时遇到一个版本兼容问题，通过 npm install vue-router --save 命令安装会提示版本不兼容，如下效果
提示版本不兼容，如果通过控制台提示执行 npm install vue-router --save --force 或 npm install vue-router --save --legacy-peer-deps 可以安装 vue-router ，但是在 Vue 项目中使用时会有无法正确引入的异常
因为默认安装的 vue-router 是4.0大版本和现在的 vue 版本不兼容，要么升级 vue , 要么降级 vue-router ，公司前端团队技术栈定的 Vue2.0 版本，果断降级 vue-router , 安装时 vue-router 时指定一个3.0的版本就行了, 执行 npm install [email protected] --save 命令即可。
src 目录创建 public-path.js 文件，如果项目 lint 校验不通过需要添加 /* eslint-disable */
修改 main.js 文件, 引入 public-path , 添加 qiankun 配置
修改 vue.config.js 文件中的打包配置
这时子应用的配置就添加好了
Vue 子应用的 @vue/cli-xxx 依赖不能为 5.0 版本，当前配置下导致无法单独运行子应用。如果是安装的最新 vue-cli 脚手架创建的项目最好看一下 @vue/cli-xxx 相关版本。
Ⅵ 前后端分离方案以及技术选型
作者：关开发
一.什么是前后端分离？
理解前后端分离大概可以从3个方面理解：
1. 交互形式
2. 代码组织形式
3. 开发模式与流程
1.1 交互形式
前后端不分离
后端将数据和页面组装、渲染好了之后，向浏览器输出最终的html；浏览器接收到后会解析html，解析引入的css、执行js脚本，完成最终的页面展示。
前后端分离
后端只需要和前端约定好接收以及返回的数据格式（一般用JSON格式），向前端提供API接口。前端就可以通过HTTP请求调用API的方式进行交互。前端获取到数据后，进行页面组装、渲染，最终在浏览器呈现。
1.2 代码组织形式
前后端不分离
在web应用早期的时候，前端页面以及后台业务数据处理的代码都放在一个工程下，甚至放在同一目录下，前端页面夹杂着后端代码。前、后端开发工程师都需要把整套代码导入开发工具才能开发。此阶段下前后端代码以及工作耦合度太高，前端不能独立开发和测试，后端人员也要依赖前端完成页面后才能完成开发。最糟糕的情况是前端工程师需要会后端模板技术（jsp），后端工程师还要会点前端技术，需要口头说明页面数据接口，才能配合完成开发。否则前端只能当一个“切图仔”，只输出HTML、CSS、以及很少量与业务逻辑无关的js；然后由后端转化为后端jsp，并且还要写业务的js代码。
前后端分离
前后端代码放在不同的工程下，前端代码可以独立开发，通过mock/easy-mock技术模拟后端API服务可以独立运行、测试；后端代码也可以独立开发，运行、测试，通过swagger技术能自动生成API文档供前端阅读，还可以进行自动化接口测试，保证API的可用性，降低集成风险。
1.3 开发模式与流程
前后端不分离
在项目开发阶段，前端根据原型和UI设计稿，编写HTML、CSS以及少量与业务无关的js（纯效果那些），完成后交给后台人员，后台人员将HTML转为jsp，并通过JSP的模板语法进行数据绑定以及一些逻辑操作。后台完成后，将全部代码打包，包含前端代码、后端代码打成一个war，然后部署到同一台服务器运行。顶多做一下动静分离，也就是把图片、css、js分开部署到nginx。
具体开发流程如下：图略
前后端分离
实现前后端分离之后，前端根据原型和UI设计稿编写HTML、CSS以及少量与业务无关的js（纯效果那些），后端也同时根据原型进行API设计，并与前端协定API数据规范。等到后台API完成，或仅仅是API数据规范设定完成之后。前端即可通过HTTP调用API，或通过mock数据完成数据组装以及业务逻辑编写。前后端可以并行，或者前端先行于后端开发了。
具体开发流程如下：图略
二、前后端分离的好处与坏处。
从上面3个方面对比了之后，前后端分离架构和传统的web架构相比，有很大的变化，看起来好处多多。到底是分还是不分，我们还是要理性分析是否值得才去做。
从目前应用软件开发的发展趋势来看，主要有两方面需要注意：
· 越来越注重用户体验，随着互联网的发展，开始多终端化。
· 大型应用架构模式正在向云化、微服务化发展。
我们主要通过前后端分离架构，为我们带来以下四个方面的提升：
· 为优质产品打造精益团队
通过将开发团队前后端分离化，让前后端工程师只需要专注于前端或后端的开发工作，是的前后端工程师实现自治，培养其独特的技术特性，然后构建出一个全栈式的精益开发团队。
· 提升开发效率
前后端分离以后，可以实现前后端代码的解耦，只要前后端沟通约定好应用所需接口以及接口参数，便可以开始并行开发，无需等待对方的开发工作结束。与此同时，即使需求发生变更，只要接口与数据格式不变，后端开发人员就不需要修改代码，只要前端进行变动即可。如此一来整个应用的开发效率必然会有质的提升。
· 完美应对复杂多变的前端需求
如果开发团队能完成前后端分离的转型，打造优秀的前后端团队，开发独立化，让开发人员做到专注专精，开发能力必然会有所提升，能够完美应对各种复杂多变的前端需求。
· 增强代码可维护性
前后端分离后，应用的代码不再是前后端混合，只有在运行期才会有调用依赖关系。应用代码将会变得整洁清晰，不论是代码阅读还是代码维护都会比以前轻松。
那么前后端分离有什么不好的地方吗？我目前是没有想到，除非你说会增加前端团队的配备，后端工程师会变的不全能。。。
二、前后端分离架构方案。
实现前后端分离，主要是前端的技术架构变化较大，后端主要变为restfull 风格API，然后加上Swagger技术自动生成在线接口文档就差不多了。
对于目前用于前后端分离方案的前端技术架构主要有两种：
· 传统SPA
· 服务端渲染SSR
2.1 传统SPA
传统SPA指的是单页面应用，也就是整个网站只有一个页面，所有功能都通过这一个页面来呈现。因为一个人的肉眼，某一个时间点看一个页面，既然如此何必要不同功能做多个页面呢？只保留一个页面作为模板，然后通过路由跳转来更新这个模板页面的内容不就可以了吗？确实如此，现在通过reac全家桶、tvue全家桶，模块化、路由、wabpack等技术轻而易举就能实现一个单页面应用。
单页面应用的运行流程
1.用户通过浏览器访问网站url
2.单页面的html文件（index.html）被下载到浏览器，接着下载html里面引用的css，js。
3.css，js下载到浏览器完成之后，浏览器开始解析执行js向后端服务异步请求数据。
4.请求数据完成后，进行数据绑定、渲染，最终在用户浏览器呈现完整的页面。
2.2 服务端渲染
服务端渲染的方案指的是数据绑定，渲染等工作都放在服务端完成，服务端向浏览器输出最终的html。大家看完这个是不是有个疑问，这不是又回到了前后端不分离的时代了吗？答案是否定的，因为这里的服务端是用来执行前端数据绑定、渲染的，也就是把浏览器的一部分工作分担到了服务端。而目前具备这只种能力的服务端是NodeJs服务端。
它的原理其实就是在浏览器与前端代码中间插入了一个NodeJs服务端。浏览器请求前端页面时，会先经过NodeJS服务端，由NodeJs去读取前端页面，并执行异步后端API，获取到数据后进行页面数据绑定，渲染等工作，完成一个最终的html然后返回浏览器，最后浏览器进行展示。
服务端渲染应用的运行流程：
1.用户通过浏览器访问网站url
2.NodeJS服务端接收到请求，读取到对应的前端html，css，js。
3.NodeJS解析执行js向后端API异步请求数据。
4.NodeJs请求数据完成之后，进行数据绑定、渲染，得到一个最终的html。
5.NodeJs向浏览器输出html，浏览器进行展示。
PS：其实本质就是把前端编写成一个nodeJs的服务端web应用。实施服务端渲染后，我们最终运行的是一个Nodejs服务端应用。而单页面应用是把静态页面部署到静态资源服务器进行运行。
看到这里，你是否又有疑问，为什么要这么麻烦搞服务端渲染呢？
2.3 SPA与服务端渲染方案对比
SPA的优点是开发简单，部署简单；缺点是首次加载较慢，需要较好的网络，不友好的SEO。
so，以下就是使用服务端渲染的理由了（摘取vue官方说法）：
与传统 SPA (单页应用程序 (Single-Page Application)) 相比，服务器端渲染 (SSR) 的优势主要在于：
· 更好的 SEO，由于搜索引擎爬虫抓取工具可以直接查看完全渲染的页面。
请注意，截至目前，Google 和 Bing 可以很好对同步 JavaScript 应用程序进行索引。在这里，同步是关键。如果你的应用程序初始展示 loading 菊花图，然后通过 Ajax 获取内容，抓取工具并不会等待异步完成后再行抓取页面内容。也就是说，如果 SEO 对你的站点至关重要，而你的页面又是异步获取内容，则你可能需要服务器端渲染(SSR)解决此问题。
· 更快的内容到达时间 (time-to-content)，特别是对于缓慢的网络情况或运行缓慢的设备。
无需等待所有的 JavaScript 都完成下载并执行，才显示服务器渲染的标记，所以你的用户将会更快速地看到完整渲染的页面。通常可以产生更好的用户体验，并且对于那些“内容到达时间(time-to-content) 与转化率直接相关”的应用程序而言，服务器端渲染 (SSR) 至关重要。
使用服务器端渲染 (SSR) 时还需要有一些权衡之处：
· 开发条件所限。浏览器特定的代码，只能在某些生命周期钩子函数 (lifecycle hook) 中使用；一些外部扩展库 (external library) 可能需要特殊处理，才能在服务器渲染应用程序中运行。
· 涉及构建设置和部署的更多要求。与可以部署在任何静态文件服务器上的完全静态单页面应用程序 (SPA) 不同，服务器渲染应用程序，需要处于 Node.js server 运行环境。
· 更多的服务器端负载。在 Node.js 中渲染完整的应用程序，显然会比仅仅提供静态文件的 server 更加大量占用 CPU 资源 (CPU-intensive - CPU 密集)，因此如果你预料在高流量环境 (high traffic) 下使用，请准备相应的服务器负载，并明智地采用缓存策略。
以vue为例，实施服务端渲染可以查看官方指南： https://ssr.vuejs.org ，或选择Nuxt.js
2.4 预渲染技术
如果你调研服务器端渲染 (SSR) 只是用来改善少数营销页面（例如 /, /about, /contact 等）的 SEO，那么你可能需要预渲染。无需使用 web 服务器实时动态编译 HTML，而是使用预渲染方式，在构建时 (build time) 简单地生成针对特定路由的静态 HTML 文件。优点是设置预渲染更简单，并可以将你的前端作为一个完全静态的站点。
如果你使用 webpack，你可以使用 prerender-spa-plugin 轻松地添加预渲染。它已经被 Vue 应用程序广泛测试 - 事实上，作者是 Vue 核心团队的成员。
prerender-spa-plugin: https://github.com/chrisvfritz/prerender-spa-plugin
三、前后端分离技术选型
- artTemplate + bootstrap（不推荐， 不算完全前后端分离）
- vue全家桶（推荐）
- react全家桶 （推荐，生态全）
Ⅶ 微前端——干坤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 方法即可
Ⅷ 轻量、高效、功能强大的微前端框架-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
到此这个简单的微应用就搭好了
觉得效果不错的请帮忙加个关注点个赞，经常分享前端实用开发技巧
Ⅸ Vue与Qiankun微前端组合
参考： https://blog.csdn.net/qq_42268364/article/details/116127872
https://gitee.com/hua0123/qiankun-demo/tree/master
https://blog.csdn.net/weixin_48726650/article/details/106905193
1、修改 App.vue
我们要在app.vue中创建一个容器，负责把获取到的子应用加载到这里容器里面
2、新建 arc/qiankun.js文件，引用qiankun并且封装好
3、修改 main.js
4、修改 src/views/Home.vue
5、修改 src/views/About.vue
6、新建 vue.config.js
1、新增 src/public-path.js
2、修改main.js
在main.js，引入public-path.js 并配合主项目导出single-spa需要的三个生命周期。
注意：路由实例化需要在main.js里面完成，以便于路由的销毁，所以路由文件只需要导出路由配置即可（原模板导出的是路由实例）
3、vue.config.js
4、修改 src/router/index.js
5、修改 src/views/Home.vue
6、修改 src/views/About.vue
7、修改 public/index.html
分别启动 main-app 和 hello-app 项目，然后访问main-app的
Ⅹ htmlcssjsvue可以找外包吗
可以。
会这些软件后可以找外包了，但是不一定能接到外包，因为需要找人外包的公司会看你的实力如何才会找你外包。
外包是指企业动态地配置自身和其他企业的功能和服务，并利用企业外部的资源为企业内部的生产和经营服务。外包是一个战略管理模型，所谓外包，在讲究专业分工的二十世纪末，企业为维持组织竞争核心能力，且因组织人力不足的困境，可将组织的非核心业务委托给外部的专业公司，以降低营运成本，提高品质，集中人力资源，提高顾客满意度。外包业是新近兴起的一个行业，它给企业带来了新的活力。