随着时代的发展，大型应用越来越多，对于维护成本也会逐渐提高，如果一整个项目的代码都在一起的话，维护的局限性会特别强

这些年，我们把大部分的目光都在用户体验上面，如何把代码写的更好，性能更快，用户体验更流畅，在做这些事情的同时，随着日复一日的项目迭代，加上业务的复杂性，我们需要花在除了正常业务开发上的时间会越来越多

然后在这种条件下，渐渐的目光转向了如何面对当前市场越来约复杂的web应用上做整体的结构优化，子应用的切分也是要保证对用户而言，他是一个完整的应用，一个国外对微前端研究较深的web开发人员认为：

一种架构风格，其中独立交付的前端应用程序被组合成一个更大的整体

其实针对 微前端 每个人都有不同的看法，我没有按照一些特定的技术方法和实现原理来告诉大家 微前端就是什么 、什么就是微前端，只是以目前的这种技术方案和市场的需求来描述这么一种应用而生的技术而已

微前端 的好处和坏处都是针对目前的一些市场反馈来总结的，不同的产品需求，针对 微前端 的反馈也是各自不同的，下面我只是总结了我已知的一些优点和缺点，剩下的还需要在未来使用微前端 的路上大家一起探索

# 增量升级（影响范围小）

一个好的产品，会在每个阶段都会进行更新迭代，以满足更多用户的需求，保证吸引更多的用户，产品的完善，版本的迭代，给开发带来的主要工作就是代码量的增加，某一个功能点可能需要对一部分的代码进行不断的更新：

# 版本一

产品初始化，我们有一个选项卡功能，需要通过数据确定有哪些tab，对应的tab显示对应的内容，这个时期，最火的框架是 jquery ，没有react 和vue，实现的过程如下：

<div id="tab-container">
 <div id="tab-btn"></div>
 <div id="tab-content"></div>
</div>
$ajax({
 url: '***',
 success: function() {
   // 这里就是获取到所有的按钮，绑定事件，点击相应的 tab 再次请求显示相应内容
   // 不写太多逻辑，明白意思即可
 }
})

@前端进阶之旅: 代码已经复制到剪贴板

这里实现了一个初始化项目开发，满足了该产品一开始的需求

# 版本二

产品维护了一段时间，用户数也在不断的上涨，发现目前的这个功能不满足用户的需求了，我们原先的头部tab 按钮保持不变，但是展示的内容变了，可能是一段文字，可能是一张图片，也有可能是一个媒体资源，而且页面不止有tab，还有很多的内容都是基于某一个状态来做动态更新的，为了保证内容的可扩展性，我们做了抽离，这个时候，有了react 和vue 框架：

// app.js
import React, { Component } from 'react'
impot TabHoc from 'TabHoc.js'
import Content1 from 'Content1.js'
import Content2 from 'Content2.js'

const HocContent1 = TabHoc(Content1, (props, method) => {
  return method(props.status)
})

const HocContent2 = TabHoc(Content2, (props, method) => {
  return method(props.status)
})

export default class App extends Component {
  constructor() {
    this.state = {
    	status: '1'
    }
  }
  componentDidMount() {
  }
  render() {
    <>
      <HocContent1 status={this.state.status}  />
      <HocContent2 status={this.state.status} />
      <... />
    </>
  }
}

// TabHoc.js

import React, { Component } from 'react'
import { Tabs } from 'antd';
const { TabPane } = Tabs;

export default function(Components, callback) {
  return class extends Component {
    constructor() {
      this.updateData = this.updateData.bind(this)
      this.updateState = (props = {
          tabList: []
        }) => callback(
        props,
        this.updateData
      )
      this.state = this.updateState()
    }
    componentDidMount() {
      axios({
        url: '***'
      }).then(({data}) => {
          this.updateState({
            tableList: data
          })
      })
    }
    updateData(obj) {
    	this.setState(prev => Object.assign({}, prev, obj))
    }
    render() {
      <Tabs defaultActiveKey={tabList[0].tab} onChange={callback}>
        {tabList.map((item,index) => {
          return (
            <TabPane tab={item.tab} key={index}>
              <Components {...this.props} data={...this.state} type={item.type} />
            </TabPane>
          )
        })}
      </Tabs>
    }
  }
}

@前端进阶之旅: 代码已经复制到剪贴板

Content1 和 Content2 的代码我没有写，后面的那个callback的方法也是大概一个意思，就是告诉大家不同的情况下，可能会有不同的展示形式，利用高阶组件（HOC）的概念对共享型数据和方法做了封装，保证代码的维护性的同时也提升了整体的性能，要比在jquery时期的渲染速度快很多，虽然功能变多了，但是由于dom的渲染是基于diff算法的，没有变化的dom 是不会进行重新渲染的

当然，版本的变化可能不止这么简单，可能更复杂，更需要不断的去重构、重构、在重构以此来优化代码，每一次的优化重构，都是会导致产品用户使用不流畅风险性的提升，没有谁敢保证某一次的更改不会影响到别的业务

这时候如果使用的是微前端方案的话，完全可以把这里独立出来，哪怕是重构，也不会影响到别的业务；如果重构的成本要比重做的成本还高（框架版本升级，性能优化等），那么重做的话基于微前端，也是一个非常安全的方案

基于微前端做增量升级最大的好处就是不论是对当前的产品进行任何 增、删、改、查 都是最方便的，风险低、效率高

# 支持多框架（灵活）

市面上的前端框架数不胜数，也各自有各自的优点，方便的框架不代表适用于我们现在的业务，如果单纯的考虑开发速度来说，vue 绝对是我认为目前市场上最方便、最快捷的框架了

但是，vue 是我们当前项目里面最好的选择吗？并不是。

上面我也说了，如果单纯是为了考虑开发效率，项目体积小，业务逻辑没有特别沉重，我还是建议使用vue的；但是如果项目比较复杂，业务逻辑依赖性也比较强的话，这个时候我就建议还是选择react 会更好一些；当然，如果你可能只是做一个活动页，宣传页之类的，前两者可能都不需要，毕竟可能只是几个div，几个事件就搞定的东西，没有必要在去搞一套框架，那样还的再去加载框架相关资源，没那个必要

多框架带来的好处很明显，当然凡事都是有两面性，合适的方式去实现合适的功能，但是整体产品来说，加载的资源就会被无限的放大：框架、构建配置、预处理语言编译器等，都是需要考虑的范围

毕竟，用户的体验才是最重要的，其次才是开发效率，但是多框架带来的上述所说的弊端也不是不可以解决，只是需要去衡量一定的方案而已

# 独立部署（安全）

后端有一个叫做server less 的概念，是前端可以借鉴的地方，也是微前端里面一个非常重要的概念

假设我们是一整个项目，没有做项目切片，项目做大以后，我们可能很多人要维护着一个项目，按照 git flow 的方式，基于 master 分支，拉了一个新的分支 dev1 ，开发过程当中，可能有多个版本，比如开发的一半的时候，我们需要有别人加入来开发新的需求，两者业务逻辑不影响，但是有公共的方法可能需要一起使用，如果我们基于 dev1 去拉一个 dev2 ，这样不合理，毕竟没有相同的需求，而且调试过程当中， dev1 的分支可能存在问题，会影响到我们接下来的开发，然而如果从 master 分支上拉一个来开发虽然看似没有问题的，但是这两版需求在合并的时候一旦出现冲突，那么这方面要耽误的时间成本就会很长了，一些复杂的逻辑，我们也不可能时时都在合并代码后做逻辑检测，对于前端或者测试来说，都是一项重复性，而又不愿意面对的问题

按照上图的方法，我们是可以规避掉这种问题的，我们的 dev1 和 dev2 都是独立的服务，维护各自的代码，可以完全避免掉因为某一个需要出现的问题而导致整个项目无法进行使用，线上项目出现类似的问题，是一件很恐怖的事情

仔细看的同学这个时候可能会问，那么独立的服务代表我们要做独立的代码分布，虽然可以通过 copy 实现功能的使用，但是这样打包的时候加载当前资源就会出现多余的内容呀？

当然，这样肯定是会出现的，我们做微前端的目的就是为了能保证用户的体验和稳定性、开发人员的维护成本和开发成本，这样的代码出现是不利于我们维护的，下面，就会讲解怎么解决类似的问题

# 共享组件库（便捷）

上述情况中就存在一个问题，代码重复性，其实平时我们有用到类似的方法，或者说见过类似的一些功能就可以解决这种问题：按需加载。

通过按需加载的方式，把公共的一些功能或者组件通过打包的方式，来实现局部加载，这样就可以解决上面所说的问题，例如 antd 中，我们 import { Button } from 'antd' , 在通过 babel-plugin-import 插件，基于 AST 把代码独立打包出来使用

antd 为我们提供了 ui组件， lodash 为我们提供了数据处理的方法，但是肯定是不难满足我们的业务需求的，但是可以借鉴此类方法

babel-plugin-import 的实现原理和 AST 相关的我就不在该文当中做详细解释了，百度一下都有

# 团队自治（沟通成本小）

一个完整的产品团队，实现产品需求只是其中的一部分，在需求的的路上，还有很多需要我们解决的问题，团队协作就是一个非常重要的点，而这个点可以直接的影响到我们产品的实用性及发展速度

假设现在我们有 a 和 b 两个功能需要开发，产品和开发都是一个团队，当业务需求特别多的时候，尤其是敏捷开发的阶段，人员的调整、需求的评审，各方各面的原因都可能导致项目有存在不难按时实现需求的情况，而且这种情况不只是靠加班解决的

一个产品不应该是按照技术团队去做划分的，而是应该按照产品的功能去做划分，在微前端的方案中，不论是 a功能还是 b功能，他们都是一个独立的团队，a团队的产品和开发去做 a功能；b团队也是如此，这样可以把当前的产品线给无限的向上发展，保证了开发的速度，也保证了因为功能沟通而浪费的时间成本

# 微前端的缺点

凡事都有两面性，没有任何一个技术方案是完美的，在解决某些问题的情况下，总会有不同的弊端出现，我们要做的就是在不同的方案面前，去衡量哪一种方案是解决我们当前产品最好的办法

# 有效的负载变大

# 管理的复杂性

这一块其实内容就很好说明了，管理的复杂性指的很多方面，业务方面、和开发方面等：

# 结束语

前面对于 微前端 发展及概念的介绍差不多就到此为止了，有什么疏忽的点还希望大家评论补充

微前端的优缺点|微前端专题

微前端的优缺点|微前端专题