vue简易微前端项⽬搭建（⼀）：项⽬背景及简介
github传送门：
1、
2、
3、
系列⽂章传送门：
最近有空，准备写个系列教程，把公司⽬前在⽤的h5项⽬从搭建到实践优化的⼀些⼼得和经验记录⼀下，技术栈是vue2.x的，马上3.0正式版就要出了，再不写就要过时啦哈哈。
1、项⽬需求
我司h5主要做移动端，运⾏在app和⼩程序⾥，也就是hybrid app混合开发模式。
刚来公司时，公司h5才刚开始起步，同事只开发了三个h5需求，这三个需求在业务功能上都是相互独⽴的，所以也分开放在了三个spa项⽬⾥。。。想⼀想，以后开发类似需求越来越多，页⾯功能⽐较分散，
⼤多都是相对独⽴的模块，难道要写n个项⽬吗，所以有必要设计⼀个多项⽬聚合⽅案。
2、关于微前端
我感觉今年随着qiankun2.0的发布，微前端概念突然⽕了很多，我记得去年也就是19年的时候还没那么⽕呢，不过确实是未来前端发展的⼀个⽅向。
在前公司的时候，有配合过后端做过微服务迁移的过程，对后端的微服务有⼀定的了解，后端⼀般是把接⼝划分为⼀些模块，每个模块就是⼀个微服务粒度，⽐如user、goods，每个模块都可以单独启动、单独修改发布。
前端页面模板⽽微前端也是借鉴后端的微服务化，把前端根据功能划分成⼏个相对独⽴的⼦项⽬，可以单独编译发布。
关于技术栈⽆关，个⼈认为对微前端来说是很有⽤的，但不是必需的，技术栈⽆关适⽤于把已有的⼏个⽼项⽬整合⼀起组成微前端，⽽如果是在微前端项⽬的⽴项搭建时就显得没那么重要了，因为搭建项⽬时选择统⼀的技术栈⽆论是开发维护还是代码复⽤都更⽅便且实际。
微前端也是前端技术发展过程中借鉴微服务后慢慢形成的⼀种架构思想，架构本⾝就是服务于业务⽽千变万化的，所以不必咬⽂嚼字去定义微前端必须具备哪些点。
本项⽬，只适⽤于vue技术栈，可以说是简易的微前端项⽬，也可以说是基于vue的多项⽬聚合⽅案。
3、关于本项⽬架构思路
技术栈选择呢，由于之前已做需求都是vue写的，也对vue相对更加熟悉，所以就选定vue作为基础框架，也便于项⽬搭建完成后把之前项⽬迁移进来，也是借鉴了前公司的⽅式。
整体上是基于vue-cli4⽣成的项⽬进⾏改造搭建，根据业务划分为多个不同的⼦项⽬，
（1）⽬录结构：
├── build                            // webpack相关配置
├── src                              // 核⼼源代码
│├── projects                      // 存储所有⼦项⽬
││├── demo                      // ⼦项⽬⽬录名
│││├── components            // ⼦项⽬公共组件
│││├── static                // 不打包的js⽬录
│││├── store                // vuex存储
│││├── utils                // 公共js
││││├── importVant.js    // vant按需引⼊
││││└── routerGuards.js  // 路由导航守卫
│││├── views                // 页⾯源码
│││├── config.js            // ⼦项⽬配置⽂件
│││└── main.js              // ⼦项⽬⼊⼝⽂件
││└──......                    // 其他⼦项⽬
│├── resources                    // 存储全局公共资源
││├── assets                    // 全局公共图⽚等
││├── components                // 全局公共组件
││├── mixins                    // 全局mixins混⼊
││├── styles                    // 全局公共样式
││├── native                    // 原⽣客户端交互封装
│││├── callNative.js        // 调⽤客户端⽅法
│││├── openNative.js        // 跳转客户端页⾯
│││├── regNative.js          // 注册js⽅法给客户端
││├── utils                    // 全局公共js
│││├── flexible.js          // rem适配
│││├── globalGuards.js      // 全局路由导航守卫公共⽅法
│││├── polyfill.js          // ⼿动添加的polyfill降级⽅法
│││└── request              // 全局接⼝请求相关
├── .env                              // 全局环境配置
├── .env.beta                        // beta环境配置
├── .env.dev                          // 本地环境配置
├── .env.prod                        // 线上环境配置
├── .st                        // test环境配置
（2）简述：
src⽬录包含projects和resources两个⽂件夹：
resources存放公共资源⽂件，
projects存放所有⼦项⽬，⾥⾯每个⽂件夹就是⼀个⼦项⽬，每个⼦项⽬相互独⽴，可以单独运⾏及打包。
部署到线上时，也是每个⼦项⽬⾪属于不同的⽬录路径，例如⼦项⽬a是test/a/index.html，⼦项⽬b是
test/b/index.html。
这样，不同的业务需求可以通过创建不同的⼦项⽬来开发，resources⾥有公共资源⽅法可以共⽤，例如公共样式、公共⽅法、客户端交互等等。
（3）优势：
1、利于多⼈多项⽬并⾏开发。在业务需求繁多、开发⼈员较多的时候，很多需求就需要并⾏开发，⼀个需求分配⼏个开发⼈员组成⼀
个临时项⽬组，并⾏独⽴进⾏开发和上线，这样就可以通过在不同的⼦项⽬下开发⽽互不影响，同时也能⽅便使⽤公共资源和组件，保证并⾏开发的效率。
2、利于发布上线时的风险分散。⼦项⽬可以单独发布，即使代码修改有严重bug，发布后也只会影响这次发布的⼦项⽬，未发布的也
就是之前已通过测试上线的可以照常运⾏。
3、提升页⾯访问速度和开发构建速度。相⽐于⼀整个⼤项⽬的⽅式，单个⼦项⽬使⽤webpack启动和构建的速度肯定更快；⽽且单个
⼦项⽬使⽤的依赖包更少，意味着打包后的js⽂件更⼩，页⾯初次访问速度就会更快。当然，在不同⼦项⽬页⾯之间来回访问的速度相对会慢不少，但由于此hybrid h5项⽬的特殊性，绝⼤多数需求模块相对独⽴，互相跳转的场景很少，合理的划分⼦项⽬即可，⽽且hybrid h5⾥很多场景下新开⼀个webview打开页⾯的体验更好，这样还是得重新加载页⾯。
（4）对⽐MPA
这⾥说的MPA是指单页⾯spa和传统多个html形式混合后的⼀种⽅式，在webpack的entry⾥配置多个⼊⼝实现，在项⽬启动和打包时都是⼀起构建的。
这种⽅式对⽐上述的三点优势，其实就只是第3点的提升页⾯访问速度算是⼀致，其他优势点都不具备。
个⼈理解MPA的主要应⽤场景是提升⾸屏访问速度。即把⾸屏页⾯单独划分出来，这样⾸屏部分打包后的js等代码就少很多，访问速度⾃然有所提升，特别是其他页⾯引⼊了很多第三⽅依赖的情况。⽽页⾯的懒加载只是路由的懒加载，未配置chunk分离的依赖打包后仍然会在初始页⾯⾥加载，没有MPA⽅式解决的更彻底。
4、项⽬配套
由于项⽬的运⾏及打包需要指定选择⼀个⼦项⽬，⼦项⽬会随着业务的发展越来越多，不可能都在package.json的script⾥写上固定的命令吧，为了提⾼命令使⽤效率，就做了个配套的脚⼿架⼯具，使⽤nodejs编写，主要⽤于创建⼦项⽬、⼦项⽬启动、打包等命令，可以⾃定义输⼊命令来指定⼦项⽬名和服务端环境。
同时也创建了个⼦项⽬模板，便于快速⽣成⼀个⼦项⽬，以及做⼦项⽬使⽤引导。
github地址见⽂章开头，业务相关代码已做清理。
5、⼦项⽬划分
这个就见仁见智了，具体还是根据公司业务需要来考虑，不⽤分太多，不然⼦项⽬太多管理也不⽅便，路由懒加载下其实⼀个⼦项⽬⾥多放些页⾯也没关系。
⽐如⼀些简单的独⽴的页⾯（例如⽤户协议、app下载页什么的）可以都放到⼀个⼦项⽬⾥
再⽐如⼀些有时效性的活动页也可以放到⼀起，⽐如中秋活动页、双⼗⼀活动页什么的，也可以按年份归纳，⽐如命名
activity2020，2020年的活动页都放这⾥。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。