A. 如何搭建web前端框架
搭建web前端框架步骤如下：
1、确定项目使用的技术
根据项目的需求等来选择使用的技术（这里以angular4 + typsescript + nodejs+mongodb举例）
2、新建一个项目的工作文件夹
使用npm init初始化项目，根据问题配置，一般是直接回车使用默认配置,生成package.json文件
3、新建一个index.html页面
4、新建配置文件system.config.js
5、新建ts的配置文件tsconfig.json
npm install typescript
6、新建webApp目录，这里面放的是所有html页面和js代码，首先得有个入口文件，与system.config.js配置文件中的入口文件名一样，app.mole.ts，里面引入了所有js文件，不被引入的在加载时都不会被加载
7、打包(将代码压缩，使程序运行速度更快）
B. 小白准备转行学习前端，有大神可以提一些建议吗
学习是以兴趣为前提的，你要对你所要学碰配的内容产生兴趣，这样你才会花心思去学习。这和是不是小白没关系的，对于小白而言，在学习过程中就需要更努力，多花时间和心思没有什么是学不会的。
自学方法：
1、作为一个初学者笑厅指，你必须明确系统的学习伏陵方案，我建议一定有一个指导的人，全靠自己学，放弃的几率非常大，在你对于web前端还没有任何概念的时候，需要一个人领进门，之后就都靠自己钻研，第一步就是确定web前端都需要哪些内容，并且在多少时间内学完，建议时间6个月保底。
2、视频为主，书为辅。很多初学者在学习前端的时候非常喜欢去买书，但是最后的结果是什么？看来看去什么都不会写，所以在这里给大家提醒，书可以看，但是是在建立于你已经对于某个知识点有了具体操作的执行后，在用书去巩固概念，这样更加利于你对于知识的理解。
3、对于学习技术来讲，掌握一个学习方法是非常重要的，其实对于学习web前端来讲，学习方法确实很多都是相通的，一旦学习方法不对，可能就会造成“方法不对，努力白费”。其实关于这方面还是很多的，我就简单说个例子，有的人边听课边跟着敲代码，这样就不对，听课的时候就专心听，做题的时候就专心做题，这都是过来人的经验，一定要听。根据每个人的不同，可能学习方法也会有所出路，找到适合你自己的学习法方法是学习的前提。
4、不建议自己一个人瞎学，在我了解学习编程的这些人来看，从零基础开始学并且最后成功做这份工作的其实并没有几个，我觉得大部分原因就是因为他们都不了解web前端是干什么的，学什么的，就盲目的买书看，到处找视频看，最后看着看着就放弃了，所以我建议初学者在没有具体概念之前，还是找有经验的人请教一下，聊过之后你就会知道web前端具体是干什么的，该怎么学，这是我个人的小建议，可以不采纳。
自学路线：
第1阶段：前端页面重构(4周)
内容包含了：(PC端网站布局项目、HTML5+CSS3基础项目、WebApp页面布局项目)
第2阶段：JavaScript高级程序设计(5周)
内容包含：(原生JavaScript交互功能开发项目、面向对象进阶与ES5/ES6应用项目、JavaScript工具库自主研发项目)
第3阶段：PC端全栈项目开发(3周)
内容包含：(jQuery经典交互特效开发、HTTP协议、Ajax进阶与PHP/JAVA开发项目、前端工程化与模块化应用项目、PC端网站开发项目、PC端管理信息系统前端开发项目)
第4阶段：移动端项目开发(6周)
内容包含：(Touch端项目、微信场景项目、应用Angular+Ionic开发WebApp项目、应用Vue.js开发WebApp项目、应用React.js开发WebApp项目)
第5阶段：混合(Hybrid,ReactNative)开发(1周)
内容包含：(微信小程序开发、ReactNative、各类混合应用开发)
第6阶段：NodeJS全栈开发(1周)
内容包括：(WebApp后端系统开发、一、NodeJS基础与NodeJS核心模块二、Express三、noSQL数据库)
视频教程：
网页链接
网页链接
如果你对于学习前端有任何不懂的可以随时来问我，如果没有比较好的教程，也可以问我要。
C. 前端基础设施怎么搞看腾讯TDesign跨技术栈组件库的最佳实践
在 6 月 28 日的首届 Techo Day 腾讯技术开放日上，腾讯发布了一系列“轻量级”产品，将腾讯多年自研产品的底层能力释放给了开发者。
正如腾讯云高级副总裁 & CTO 王慧星，在前不久的腾讯 TDesign 技术生态日提到的那样：“自腾讯确立了开源协同，自研上云的技术战略，成立了十大技术领域委员会，推出了众多 PaaS 能力，并将这样的能力放在云上，实现对内部和外部用户的统一服务。”
而腾讯设计云旗下的企业级产品设计体系腾讯 TDesign 正是这样一款产品，其也在首届 Techo Day 腾讯技术开放日活动中，发布了新的产品动态。据了解，目前腾讯 TDesign 的大部分组件已经完成了内测版本的发布， Vue 2、Vue 3、React 和移动端 Vue 3 也已经发布了公测版本和候选版本。与此同时，Augular、Flutter 、taro 等热门技术栈也在开发的行列当中。
如果要回溯腾讯自研 UI 组件库的缘由，这或许要先了解下前端领域的发展史。
纵览底层的前端框架领域，先是经历了 JQuery 一统江湖的时代，而后过渡到了 MVVM 框架成为主流的时期。目前，Vue、React 以及 Angular 则成为了前端开发人员使用最多、最广的底层框架。可以看出，业界并没有完全占据主导地位的前端开发框架，这也就导致前端技术团队在迭代技术栈时，往往存在较大的切换成本，跨团队共享前端资产时也会遇到技术栈差异的壁垒。
此外，由于组件库和团队技术栈存在一定耦合性的关系，对于很多企业中后台系统这样的弱设计风格场景，我们可以根据整个栈的风格，大致推测出这个项目使用了哪种组件库。例如，前端团队选择了 React 开发框架，大概率会用 AntD 组件库；使用 Vue 开发框架，则大概率会直接用 iview-admin 页面模板。这样一来，技术栈的差异不仅会导致整个组件库的选型受到一定限制，还会让对外曝露的产品体验存在较大的偏差。
因此，在产品体验、开发效率与设计效率等因素的驱动下，腾讯通过开源协同的方式，与多个业务团队共建了企业级设计体系腾讯 TDesign ，通过提供复用性的设计体系，为设计研发各个流程环节提供需要的设计和研发等解决方案。
在代码组件库中，腾讯 TDesign 基于业界实际的使用需求，已经覆盖了 Vue、Vue Next、React 等主流的前端开发框架，目的在于让公司内外部使用的同学都可以根据自身实际需求，选择对应的组件库产品，不再受技术选型的限制。当项目同时有桌面端和移动端使用需求的时候，腾讯 TDesign 还可以统一产品在两端上的业务体验。
从另一个角度来看，如果没有统一的 UI 组件体系，UI 设计师的工作效率同样是大打折扣的。在“腾讯前端通用 UI 组件库技术生态日”活动中， 腾讯用户研究与体验设计部总经理陈妍说道：“如果没有腾讯 TDesign 这样的 UI 组件库，设计师是最大的受害者，因为我桥核孝们的工作需要不断的重复，没有办法把时间节省下来做更加有价值的事情。”
基于设计敏稿师的痛点，腾讯 TDesign 目前也提供了 Figma、Sketch、Axure 等设计资源以及 Sketch 设计插件，让设计和代码能够无缝衔接，使设计资源分配到必要的环节。
既然腾讯 TDesign 选择了支持各种技术栈的原生开发，就不可避免地会遇到几类问题。例如，UI 组件库怎么保证与技术栈产物一致性？交互和 UI 实现怎么保持一致？组件 API 怎么保持一致？官网体验与用户氏并的实际使用如何保持一致？
据腾讯 TDesign 团队透露，虽然业界基于上述挑战已经有几种不同实现的方式，但其各有优劣：
一种方案是基于 Web Components 做一个组件，将其使用在各个框架当中，但 Web Components 方案的优势与具体实现框架没有太大关系，因为是由浏览器原生支持，其最大的问题还是浏览器的兼容性，部分浏览器可以通过 polyfill 解决，但是有些政企浏览器的兼容性依然是不可小觑的问题。
另一种方案是直接将一份 React 代码转成 Vue，这带来的好处是可以真正做到维护一份代码，同时支持多技术栈，但统一整个前端技术栈其实是比较大的课题，目前业界还没有统一的方案。另外，代码转换支持多技术栈的方案，其实在应用开发层会更常见，对于腾讯 TDesign 这种底层依赖而言，转化后代码的稳定性还是难以得到保障。
不仅于此，这种转化方案的中间层代码相当于是新的框架，既不是 Vue，也不是 React，对于贡献者来说门槛比较高，会进一步导致开源社区不够活跃，这同样是腾讯 TDesign 团队需要考虑的问题。
最终，腾讯 TDesign 团队决定选择用 Vue 开发 Vue 技术栈，React 开发 React 技术栈，除了 Angular、小程序等受技术栈限制，其他技术栈均统一用 Jsx 来维护组件实现，并主要解决了以下几个问题：
组件 API 保持一致
腾讯 TDesign 团队梳理出了开源项目前端组件上线的流程，在组件进入开发的前置阶段，设置了 API / 交互稿统一评审环节，邀请各技术栈的实现者、UI/ 交互设计师以及 PMC 成员同学一起针对组件 API 的易用性、灵活性以及必要性进行评审，充分的讨论过后，会将大家的意见形成整个组件的 API 描述，并录入腾讯 TDesign 的组件 API 管理平台。
最终，API 管理平台会生成各个技术栈的 API 文档、某个组件的 props.ts、typeb.ts 等文件。当组件开发者进行开发时，不需要对照文档做开发，直接根据已经生成的定义文件开发即可，做 API 开发同学提了 PR 做 review 时，有任何更改会同步到各个技术栈实现的仓库。
用户实际使用与官网体验保持一致
为了让用户的实际使用感受与官网体验保持一致，腾讯 TDesign 做了一层官网共同的架构，目前所有的组件文档包括文字部分，以及我们要展示的组件 Demo。各个端实现时，会各自引入一个 Web Components 实现官网的公共部分，通过统一的 Markdown 解析工具，最终解析出来的栈点就会完全一样。
各个技术栈产物的 UI 和交互保持一致
除了要保证组件 API 一致，还要保证各个技术栈的产物里 UI 和交互都要完全一样，这里 TDesign 做了两件事情：第一，以 TDesign Token 贯穿设计开发流程，从最初设计师提供的设计稿，到组件库里代码的实现变量，一直到最终组件库里面 NPM 包产物，每个变量都有一一对应的关系；第二，抽取一个独立的仓库，将每个组件都独立维护在 TDesign-common 仓库，通过 Submole 的方式引入到实现仓库里。当 UI 需要调整的时候，直接在独立的库里修改，再同步到各个技术栈实现的仓库，最终保证整个 UI 和交互在各个技术栈上面实现完全一样。
部分组件代码复用
除了 UI 相关实现代码做到了各技术栈复用，腾讯 TDesign 也参考了业界类似组件库产品的实践， 探索 了一些代码逻辑复用的方案：一些与技术栈无关的组件抽象类，也抽取到了 TDesign-common 仓库中；合理分层组件实现，通过 Hooks 和 Composition API 来跨技术栈复用部分代码实现。
据了解，当前腾讯 TDesign 在内外部已经有了比较广泛的应用基础，腾讯内部在积极推动各个业务统一到 TDesign，也支持了多个领域和行业外部项目落地，并从中孵化出了多个行业组件库。这些组件库也将在未来逐步开源，持续支持各行业领域的系统建设。
而当我们开始回溯腾讯 TDesign 自开源以来的历程，可以发现其取得的成绩已经可圈可点：在开源社区的建设方面，腾讯 TDesign 仍然秉持着为社区贡献价值的初心，不断向有活力、高质量的开源社区进阶。据统计，上半年 TDesign 共有 280+ 贡献者，其中外部 17 ，核 贡献者 47 ，GitHub star 4k+。
展望未来，腾讯 TDesign 还将继续围绕着两个既定目标迈进：
第一，让更多人使用腾讯 TDesign。后续组件库各技术栈将发布 Stable 版本，并针对移动端开展专项优化，以确保提升组件质量和用户使用体验。为了最大化提升设计师的工作效率，还将提供 模板、移动端 Figma UIKit Variant（设计可配置能 ）等设计资源，并建设物料市场，承载更多的 业组件和模板资源。除此之外，TDesign 还计划支持国际化以及无障碍适老化的适配；
第二，建设更有活 、更 质量的开源社区。为了帮助更多从业者了解企业级设计体系 腾讯 TDesign，社区后续计划沉淀、总结设计体系和组件库专业 章 / 课程。另外，为了吸引更多外部开发者加 贡献，透明化内外部协作进度，开源社区将优化开发者的招募和激励机制。
谈及未来的发展规划，腾讯 TDesign 团队在接受 InfoQ 采访时表示，未来除了会支持现有的前端技术栈，还将协同社区的力量推出 Web components、Flutter 等更多技术栈产品，服务于公司内外使用者。同时，也期待更进一步复用跨框架实现的代码，在降低维护成本的同时，不显着额外提升参与贡献的门槛。
作为腾讯设计云的关键产品，腾讯 TDesign 的诞生便是为了让 UI 组件库摆脱技术选型的影响，让其回归到前端基础设施的地位上来。事实证明，在一步步的迭代与优化之下，腾讯 TDesign 已经逐步地将开源协同能力渗透给了更多企业。
与此同时， 腾讯用户研究与体验设计部总经理陈妍还在接受 InfoQ 采访时透露：未来，腾讯设计云将继续在设计资产、设计协作效率发力，针对图标库、设计资产开源平台以及智能设计工具进行迭代升级。目前，腾讯设计云已经初步完成平台建设阶段，后续腾讯设计云将逐步向内容建设方面进阶。
我们也坚信，今后腾讯设计云在实现高效设计、轻松协同目标的过程中，也将迈出更加坚实的一步。
D. 2020年前端最火的技术是什么
我认为最火的技术有三个：TypeScript、Vue3.0、JAMStack
原因：
1、TypeScript 是一门基于 JavaScript 基础之上的编程语言，很多时候我们都在说它是一个 JavaScript 的超集，或者叫扩展集。所谓超集，其实就是在 JavaScript 原有的基础之上多了一些扩展特性。多出来的呢，实际上就是一套更强大的类型系统，以及对 ECMAScript 新特性的支持。而且它最终会编译为原始的 JavaScript。
相比较于 Flow，TypeScript 作为一门完整的编程语言，它的功能更为强大。生态也更健全、更完善。特别是对于开发工具这一块，微软自家的开发工具对 TypeScript 的支持都特别友好。
2、Vue 是“一个用于构建用户应用程序的渐进式框架”。它的设计非常灵活，可以将单个 Vue 库集成到其他项目中，也可以完全使用 Vue 构建复杂的项目。Vue 通常被视为一个易于理解和实现的框架，它支持纯 HTML 模板，而 React 需要使用 JavaScript 定义来 DOM 元素。
速度更快是 Vue 目前的主要卖点之一,Vue 以其渲染速度而闻名，与其他框架一样，Vue 使用虚拟 DOM 来渲染组件。为了加速渲染过程，必须减少虚拟 DOM 的工作负载。通过编译时间提示、组件快速路径、单态调用、优化 slot 生成等手段来达到提速目的。
体积小
目前，Vue 的体积已经很小了（压缩后 20KB）。由于进行了摇树优化（消除非重要代码），3.0 的预计大小约为 10KB（压缩后）。主要是移除了对 Vue 项目来说不是很重要的库，可以通过 import 语句来使用它们，而不是把它们打包在主 src 代码中。
可维护性
Vue 3.0 将从 Flow 转到 TypeScript，同时又非常重视兼容性易用性，不喜欢使用 TypeScript 的用户仍然可以使用纯 JavaScript。Vue 3.0 提供了更好的模块化，从而变得更加可定制和灵活，还提供了透明性，开发人员可以深入到源代码中。编译器重写是最令人兴奋的功能之一，不仅带来了更好的 IDE 支持，而且可以创建源码映射，如果存在运行时错误，它将给出错误对应的文件位置和行号。
面向原生
Vue 3.0 将与平台无关——它将运行纯 JavaScript，并且在其主构建中不会假设使用诸如 Node.js 之类的东西。这种灵活性使构建 Web、iOS 或 Android 应用程序变得更容易。面向原生使 Vue 更像是 React 的替代品。
易用性
公开 Reactivity API——新的变更允许开发人员显式创建反应式对象和自定义重渲染 hook。3.0 还解决了 Vue 用户经常抱怨的一个问题：什么时候以及为什么要重新渲染组件？3.0 提供了一个 renderTriggered 事件，人们可以通过它查看是什么触发了更新。这个出色的功能将使 Vue 更加透明。
3、JAMstack是指使用JavaScript、API和Markup构建的技术堆栈，JAM是JavaScript、API和Markup的简称，前面第一个字母缩写，JAMstack一种基于客户端JavaScript，可重用API和预构建Markup的现代Web开发架构
1. 更好的性能：为什么要在部署时生成页面时等待页面动态构建？当谈到最小化第一个字节的时间时，没有什么能比通过CDN提供的预构建文件更好。
2. 安全性更高：将服务器端进程抽象为微服务API，可以减少攻击的表面区域。您还可以利用专业第三方服务的专业知识。
3. 更便宜，更容易扩展：当您的部署相当于可以在任何地方提供服务的一堆文件时，扩展就是在更多地方提供这些文件的问题。CDN是完美的，通常包括扩展他们的所有计划。
4. 更好的开发者体验：松散耦合和控制分离允许更有针对性的开发和调试，并且为站点生成器扩展选择CMS选项消除了为内容和营销维护单独堆栈的需要。
所以我认为最火的技术应该就是这三个。
E. 前端常用的框架有哪些
有三大主流框架，分别为：Angular、vue、react
1、我们在大型超大型web应用开发上，看好Angular：
深度整合Typescript和Rxjs。ts解决了工程化的问题，rxjs解决了开发速度的问题。但是学习成本，可能对于Java，c#等OOP工程师来说比较容易上手，但是对于JavaScript工程师来说，少有工程化的经验，接受起来比较痛苦。当然，不只是Angular可以采用Typescript开发，很多其他的Dom库都可以，Angular相比他们的优势在于：
1.零配置
2.深度整合设计模式
3.约定才是框架的本质
2、小型应用上，看好vue
其实绝大部分web应用，都应该只是小型应用。公司官网，论坛，甚至是规模不大的电子商务网站和基本功能的OA，ERP系统，都只是小型web应用。它们数据源稳定，对于运营的要求不高，但是对加载速度等都有很高的要求。这个时候，小巧的vue就成了首选。Proxy实现的响应式相比Angular的zone暴力代理和rxjs的复杂操作显得更加接地气，不需要额外地进行学习。对象式的声明在UI实现上速度更快。生态虽然没有react那么热闹但是小而美的库也很多，nuxt的实现值得点赞。
3、个性化需求、中型应用，更倾向react
在中大型应用中，不是一定要搞Java那一套的，而且在前端这种对工期要求很紧的领域，没必要因为添加新功能而更换新的平台，能用到rxjs和依赖注入的前端应用场景并不多。所以如果采用react，从项目一开始就渐进式地添加模块，往往更适合快速发展的产品。
F. 从0搭建React+antd+TypeScript+Umi Hooks+Mobx前端框架
因为现在公司的主要技术栈是React,所以也想着能够搭建一个好的React前端框架，方便在工作中使用；框架在打包过程也做了优化，多线程，拆包，缓存等等手段提升打包速度和质量。主要用到的库包括：
创建带TypeScript模板的react-app，推荐使用yarn,接下来我也主要以yarn做例子
然后在项目根目录创建一个 craco.config.js 用于修改默认配置。antd按需加载以及自定义主题
重新打包就可以了， 所有的主题配置在这里噢
这里利用React-router做路由，同时也会根据用户角色，做权限处理；只有当角色和路由允许的角色一致时才可以访问和展示。
新建router下新建indext.tsx 用于渲染页面
引入Router/index.tsx
新建hasPermission.ts,如果页面 roles 包括用户的角色则返回true,在渲染menu和子页面的时候就根据这个值渲染页面。
比如Home页面，渲染子页面的逻辑：
在这里 SubPages1 下面的 page1 就无法展示出来和访问，如果直接输入路由也会访问页面不存在，因为page1允许的角色 user 而我们角色是 admin 所以无法展示。
useImmer 很好的解决了ReactHooks中的赋值的性能问题，可以单独更新某个对象的某个属性。
上面的赋值方法也可以写到一起,效果是一样的：
Umi Hooks 是一个 React Hooks 库，致力提供常用且高质量的 Hooks。提供了非常多的Hooks组件，比如上面使用的 usePersistFn ，他的作用：在某些场景中，你可能会需要用 useCallback 记住一个回调，但由于内部函数必须经常重新创建，记忆效果不是很好，导致子组件重复 render。对于超级复杂的子组件，重新渲染会对性能造成影响。通过 usePersistFn ，可以保证函数地址永远不会变化。Umi Hooks功能还是非常强大的，有很多功能很强大的API。大家可以去官方文档看看 https://hooks.umijs.org/zh-CN/hooks/life-cycle/use-update-effect 。
自定义 hooks 其实在我们的开发工作中，还是很常遇到的。 hooks 的好处就是可以抽离公共方法，像组件一样的随意使用，对于快节奏的开发工作还是很舒服的，比如你觉得 react hooks 或者 umi hooks 的api，不能满足自己的需求，也可以自己创新一些api。我这里举个例子，大家写 class 组件写的很多的话，会经常用的 this.setState() ，大家都知道 this.setState() 是异步执行，你无法直接拿到最新的 state 。 hooks 中的 useState 同样也是异步的，你无法直接获取到最新的 state ，所以我自己写了一个 useSetState 方法，用于在修改完状态后能够立即拿到最新的 state 。
我们在src/hooks文件夹下新建 useSetState.ts
使用的方式也很简单，基本和useState一致，只是在setState的时候提供一个回调函数。
这就完成了带回调的 useSetState hooks 的编写，不过这种写法不太推荐在 hooks 中使用，建议需要获取最新的数值都在 useEffect 或者 useUpdateEffect(umi hooks) 中去。
状态管理选择的Mobx,Mobx和Rex我都用过，不过当我习惯用Mobx后，就感觉还是Mobx更方便一些，所以更喜欢在项目中用Mobx,现在Mobx已经更新到5.0版本了，不过5.0版本并不支持ie11，所以如果想要兼容性可以选择4.0的版本，或者Rex。
这里推荐一个针对Mobx的库， mobx-react-lite :它是基于 React 16.8 和 Hooks 的 MobX 的轻量级React绑定。
这个主要影响的是调用方法的形式，对于Mobx的书写是一样的，比如写一个加减数值：
这里你的typeScirpt可能会编译不了，会报错：Experimental support for decorators is a feature that is subject to change in a future release. Set the 'experimentalDecorators' option in your 'tsconfig' or 'jsconfig' to remove this warning.
解决方法是在 tsconfig.json 加入配置：
完毕以后，一定要把 storeProvider 包裹所需要共享状态的页面，我这里直接放到app.tsx
剩下来就仅仅是调用的事情了：
此外axios的配置应该大家都知道，所以我这也不多说了，具体在我的源码里面也有，utils下的axios.ts
加入了打包分析 webpack-bundle-analyzer speed-measure-webpack-plugin
加入了打包进度条 webpackbar
加入了打包压缩 compression-webpack-plugin terser-webpack-plugin
还对包进行拆包
开发环境的域名代理 devServer
加快打包速度，还可以考虑删除antd-icons，单独去iconfont网站下，按需引入。不然打包会费很多时间
引入dotenv-cli
新增开发环境配置文件 .env.development 和 .env.proction 两个文件
然后修改package.json中的启动脚本：
现在 yarn start 或者 yarn build 就会根据环境配置来处理。
还有一些细节的调整，会尽力将这个框架更加完善的。
github地址： https://github.com/Benzic/React-typescript-umihooks-mobx
欢迎star 和提意见
G. 基于Vue3+TS+ElementPlus+Qiankun构建微应用项目
Hello 大家好，这里是Anyin。
最近打算把一个小型项目（小程序点餐系统）重构为微服务+微应用模式，前端的技术栈打算使用Vue3 + TS + ElementPlus + Qiankun 。这里记录下我在构建基础微应用的过程。
重构后的项目相关地址：
•后端： Anyin Cloud [1]
•前端基座： Anyin Cloud Parent[2]
•前端微应用： Anyin Cloud Base[3]
好了，接下来，我们来看看如何基于 Vue3+TS+ElementPlus+Qiankun 构建我们的微应用项目。
另外说下，这正销猛里为什么不用 Vite 进行构建，原因是 Vite 目前结合 Qiankun 构建为应用还有点问题（采坑了），所以这里就放弃了。
首先，我们使用 vue-cli 创建一个parent项目:
接着，手动选择我们要添加的组件：
我们选择以下组件进行应用的构建，使用空格键进行多选，然后回车即可：
选择vue3.x版本
相关代码风格、路由模式都是使用默认，css编译我们使用less：
相关编码规范我们使用ESLint + Airbnb Config ：
最后，完整的选项如下：
当vue-cli帮我们创建好项目，我们进入项目查看下项目目录，如下：
首先，Qiankun的主应用是需要安装依赖的，微应用无需安装依赖，修改配置即可。这里我们先在主应用安装依赖
接着，进行相关微应用配置。我们新增一个 app.ts ，用于记录所有的微应用斗慧的入口：
然后，注册微应用，并导出start方法
导出 start 方法之后，需要在入口处执行该方法
对于整个界面，我们希望整体的布局是这个样子的：
所以，我们在安装 ElementPlus 之后，需要做这样子的布局。
首先，安装 ElementPlus
接着，在 main.ts 引入 ElementPlus 组件，如下:
然后，创建一个布局组件 Layout.vue ，如下：
最后，在App.vue注册该组件
运行起来呈现的效果如下：
微应用的初始化项目同主应用，这里就不详细说明。
微应用无需依赖 Qiankun ，这里我们做一些配置即可。
在 src 目录下新增一个 public-path.js 文件，内容如下：
在 main.ts 引入该文件
新增一个路由配置文件，这里我们创建对应的路由信息，并且兼容独立运行，内容如下：
接着，修改 main.ts 关于实例化的代码，如下：
这里主要是定义个渲染的方法，然后暴露举桥Vue实例，因为等下在微应用的生命周期的钩子会使用到。
对于微应用还需要暴露生命周期的钩子方法，这样子主应用才能够识别，在 main.ts 添加如下方法：
使用 vue 创建项目是没有 vue.config.js 文件的，这里我们手动创建一个，并且配置相关详细，代码如下：
•这里我们导入了 package.json 的 name 字段，因为这里需要和主应用配置的 app.ts 文件的 name 字段一致 • headers 添加跨域配置，因为主应用是通过 fetch 方法来获取微应用的资源的，而微应用是启动在另外一个端口，所以需要添加跨域配置 • output 配置了微应用的打包格式，主应用才能正确识别微应用的一些配置
还记得我们以下这个图不？
我认为 Header 应该是属于主应用，而下面的 Aside 和 Main 都是属于微应用， Aside 块一般都是用于展示菜单，个人认为各个微应用应该各自维护自己的菜单，而不是交由主应用维护。
所以，在微应用，我们还需要处理下左侧的菜单布局。
我们新增一个 Layout.vue 布局文件
至此，Vue3+TS+ElementPlus+Qiankun构建微应用项目的一个基本结构我们已经处理完成，整体运行看下效果：
首页
微应用
好了，基于 Vue3+TS+ElementPlus+Qiankun 的微应用项目基本框架我们已经搭建好了，后续就是慢慢填充一些工具和页面了。
相关源码地址：
•主应用： Anyin Cloud Parent
•微应用： Anyin Cloud Base
[1] Anyin Cloud : https://gitee.com/anyin/anyin-cloud
[2] Anyin Cloud Parent: https://gitee.com/anyin/anyin-cloud-parent
[3] Anyin Cloud Base: https://gitee.com/anyin/anyin-cloud-base