把一个div元素的属性打印出来，如下：
可以看到仅仅是第一层，真正DOM的元素是非常庞大的，这也是DOM加载慢的原因。
相对于DOM对象，原生的JavaScript对象处理起来更快，而且更简单。DOM树上的结构、属性信息都可以用JavaScript对象表示出来：
上面对应的HTML写法是：
DOM树的信息可以用JavaScript对象表示出来，则说明可以用JavaScript对象去表示树结构来构建一棵真正的DOM树。
状态变更->重新渲染整个视图的方式可以用新渲染的对象树去和旧的树进行对比，记录这两棵树的差异。两者的不同之处就是我们需要对页面真正的DOM操作，然后把它们应用在真正的DOM树上，页面就变更了。这样可以做到：视图的结构确实是整个全新渲染了，但是最后操作DOM的只有变更不同的地方。
吾日三省吾身在等待后端老哥接口的时候，看到一则说面试题为什么百度搜索这么快的一个问题？虽然这是面试的后端，但是作为前端，如果问为什么类似vue，react这些会有生命周期？有什么用？那如果这样问我，我感觉空气会突然安静几秒…仔细一想貌似也不是很难理解,在使用这类框架编码时我们会发现除了html有个id为app的div是给vue挂载，其他什么都没有，在webpack打包完成后会生成一个app.js
等关键字眼都是可以搜索到对应的方法，那我们就推出所谓的生命周期就是vue执行函数的一个先后顺序的过程，也就是有了生命周期的这个概念，因为每个阶段负责不同的事情，所以要在对应的函数里写对应的业务逻辑。下面在了解下虚拟dom是什么，我大概提炼下，浏览器在编译我们的html文件呈现给用户看时是一个较为复杂的过程，在我们改界面中改变多个值展示时，如果传统的改了多个值浏览器在接受第一个值时就立马跑去更新了后面的依次。。(是个勤快的浏览器),但是这样是不是有点蠢了？ 假如10个节点要跟新我们一次性告诉他不就行了，不要让他来回跑了，你不累我看着都累，然后工程师的工程师就出来了说，嗯我用js可以实现~~下面是看到的讲解，觉得非常精妙与大家分享下
浏览器渲染引擎工作流程都差不多，大致分为5步，
第一步，用HTML分析器，分析HTML元素，构建一颗DOM树(标记化和树构建)。
第二步，用CSS分析器，分析CSS文件和元素上的inline样式，生成页面的样式表。
第三步，将DOM树和样式表，关联起来，构建一颗Render树(这一过程又称为Attachment)。每个DOM节点都有attach方法，接受样式信息，返回一个render对象(又名renderer)。这些render对象最终会被构建成一颗Render树。
第四步，有了Render树，浏览器开始布局，为每个Render树上的节点确定一个在显示屏上出现的精确坐标。
第五步，Render树和节点显示坐标都有了，就调用每个节点paint方法，把它们绘制出来。
DOM树的构建是文档加载完成开始的？构建DOM数是一个渐进过程，为达到更好用户体验，渲染引擎会尽快将内容显示在屏幕上。它不必等到整个HTML文档解析完毕之后才开始构建render数和布局。
Render树是DOM树和CSSOM树构建完毕才开始构建的吗？这三个过程在实际进行的时候又不是完全独立，而是会有交叉。会造成一边加载，一遍解析，一遍渲染的工作现象。
CSS的解析是从右往左逆向解析的(从DOM树的下－上解析比上－下解析效率高)，嵌套标签越多，解析越慢。
用我们传统的开发模式，原生JS或JQ操作DOM时，浏览器会从构建DOM树开始从头到尾执行一遍流程。在一次操作中，我需要更新10个DOM节点，浏览器收到第一个DOM请求后并不知道还有9次更新操作，因此会马上执行流程，最终执行10次。例如，第一次计算完，紧接着下一个DOM更新请求，这个节点的坐标值就变了，前一次计算为无用功。计算DOM节点坐标值等都是白白浪费的性能。即使计算机硬件一直在迭代更新，操作DOM的代价仍旧是昂贵的，频繁操作还是会出现页面卡顿，影响用户体验。
Web界面由DOM树(树的意思是数据结构)来构建，当其中一部分发生变化时，其实就是对应某个DOM节点发生了变化，
虚拟DOM就是为了解决浏览器性能问题而被设计出来的。如前，若一次操作中有10次更新DOM的动作，虚拟DOM不会立即操作DOM，而是将这10次更新的diff内容保存到本地一个JS对象中，最终将这个JS对象一次性attch到DOM树上，再进行后续操作，避免大量无谓的计算量。所以，用JS对象模拟DOM节点的好处是，页面的更新可以先全部反映在JS对象(虚拟DOM)上，操作内存中的JS对象的速度显然要更快，等更新完成后，再将最终的JS对象映射成真实的DOM，交由浏览器去绘制。
例如一个真实的DOM节点。
我们用JS来模拟DOM节点实现虚拟DOM。
其中的Element方法具体怎么实现的呢？
第一个参数是节点名（如div），第二个参数是节点的属性（如class），第三个参数是子节点（如ul的li）。除了这三个参数会被保存在对象上外，还保存了key和count。其相当于形成了虚拟DOM树。
有了JS对象后，最终还需要将其映射成真实DOM
我们已经完成了创建虚拟DOM并将其映射成真实DOM，这样所有的更新都可以先反应到虚拟DOM上，如何反应？需要用到Diff算法。
两棵树如果完全比较时间复杂度是O(n^3)，但参照《深入浅出React和Redux》一书中的介绍，React的Diff算法的时间复杂度是O(n)。要实现这么低的时间复杂度，意味着只能平层的比较两棵树的节点，放弃了深度遍历。这样做，似乎牺牲掉了一定的精确性来换取速度，但考虑到现实中前端页面通常也不会跨层移动DOM元素，这样做是最优的。
深度优先遍历，记录差异 。。。。
在实际代码中，会对新旧两棵树进行一个深度的遍历，每个节点都会有一个标记。每遍历到一个节点就把该节点和新的树进行对比，如果有差异就记录到一个对象中。
下面我们创建一棵新树，用于和之前的树进行比较，来看看Diff算法是怎么操作的。
1、节点类型变了，例如下图中的P变成了H3。我们将这个过程称之为REPLACE。直接将旧节点卸载并装载新节点。旧节点包括下面的子节点都将被卸载，如果新节点和旧节点仅仅是类型不同，但下面的所有子节点都一样时，这样做效率不高。但为了避免O(n^3)的时间复杂度，这样是值得的。这也提醒了开发者，应该避免无谓的节点类型的变化，例如运行时将div变成p没有意义。
2、节点类型一样，仅仅属性或属性值变了。我们将这个过程称之为PROPS。此时不会触发节点卸载和装载，而是节点更新。
3、文本变了，文本对也是一个Text Node，也比较简单，直接修改文字内容就行了，我们将这个过程称之为TEXT。
4、移动／增加／删除 子节点，我们将这个过程称之为REORDER。看一个例子，在A、B、C、D、E五个节点的B和C中的BC两个节点中间加入一个F节点。
我们简单粗暴的做法是遍历每一个新虚拟DOM的节点，与旧虚拟DOM对比相应节点对比，在旧DOM中是否存在，不同就卸载原来的按上新的。这样会对F后边每一个节点进行操作。卸载C，装载F，卸载D，装载C，卸载E，装载D，装载E。效率太低。
如果我们在JSX里为数组或枚举型元素增加上key后，它能够根据key，直接找到具体位置进行操作，效率比较高。常见的最小编辑距离问题，可以用Levenshtein Distance算法来实现，时间复杂度是O(M*N)，但通常我们只要一些简单的移动就能满足需要，降低精确性，将时间复杂度降低到O(max(M,N))即可。
虚拟DOM有了，Diff也有了，现在就可以将Diff应用到真实DOM上了。深度遍历DOM将Diff的内容更新进去。
我们会有两个虚拟DOM(js对象，new/old进行比较diff)，用户交互我们操作数据变化new虚拟DOM，old虚拟DOM会映射成实际DOM(js对象生成的DOM文档)通过DOM fragment操作给浏览器渲染。当修改new虚拟DOM，会把newDOM和oldDOM通过diff算法比较，得出diff结果数据表(用4种变换情况表示)。再把diff结果表通过DOM
虚拟DOM的存在的意义？vdom 的真正意义是为了实现跨平台，服务端渲染，以及提供一个性能还算不错 Dom 更新策略。vdom 让整个 mvvm 框架灵活了起来
Diff算法只是为了虚拟DOM比较替换效率更高，通过Diff算法得到diff算法结果数据表(需要进行哪些操作记录表)。原本要操作的DOM在vue这边还是要操作的，只不过用到了js的DOM fragment来操作dom（统一计算出所有变化后统一更新一次DOM）进行浏览器DOM一次性更新。其实DOM fragment我们不用平时发开也能用，但是这样程序员写业务代码就用把DOM操作放到fragment里，这就是框架的价值，程序员才能专注于写业务代码。
高阶组件由于每次都会返回一个新的组件，对于react来说，这是不利于diff和状态复用的，所以高阶组件的包装不能在render 方法中进行，而只能像上面那样在组件声明时包裹，这样也就不利于动态传参。
2、复用性强，HOC为纯函数且返回值为组件，可以多层嵌套
3、支持传入多个参数，增强了适用范围
1、当多个HOC一起使用时，无法直接判断子组件的props是哪个HOC负责传递的
2、多个组件嵌套，容易产生同样名称的props
3、HOC可能会产生许多无用的组件，加深了组件的层级
react的数据流是单向的，最常见的就是通过props由父组件向子组件传值。
父向子通信：传入props
子向父通信：父组件向子组件传一个函数，然后通过这个函数的回调，拿到子组件传过来的值
1、找一个相同的父组件，既可以用props传递数据，也可以用context的方式来传递数据。
2、用一些全局机制去实现通信，比如redux等
React 合成事件（SyntheticEvent）是 React 模拟原生 DOM 事件所有能力的一个事件对象，即浏览器原生事件的跨浏览器包装器。
为什么要使用合成事件？
进行浏览器兼容，实现更好的跨平台
React 采用的是顶层事件代理机制，能够保证冒泡一致性，可以跨浏览器执行。React 提供的合成事件用来抹平不同浏览器事件对象之间的差异，将不同平台事件模拟合成事件。
事件对象可能会被频繁创建和回收，因此 React 引入事件池，在事件池中获取或释放事件对象。即 React 事件对象不会被释放掉，而是存放进一个数组中，当事件触发，就从这个数组中弹出，避免频繁地去创建和销毁(垃圾回收)。
方便事件统一管理和事务机制
在 React 中，“合成事件”会以事件委托方式绑定在 document 对象上，并在组件卸载（unmount）阶段自动销毁绑定的事件。
当真实 DOM 元素触发事件，会冒泡到 document 对象后，再处理 React 事件；所以会先执行原生事件，然后处理 React 事件；最后真正执行 document 上挂载的事件。
合成事件和原生事件最好不要混用。原生事件中如果执行了stopPropagation方法，则会导致其他React事件失效。因为所有元素的事件将无法冒泡到document上，所有的 React 事件都将无法被注册。
合成事件对象池，是 React 事件系统提供的一种性能优化方式。合成事件对象在事件池统一管理，不同类型的合成事件具有不同的事件池。
在 React 中，render 执行的结果得到的并不是真正的 DOM 节点，而是轻量级的 JavaScript 对象，我们称之为 virtual DOM。它通过JS的Object对象模拟DOM中的节点，然后再通过特定的render方法将其渲染成真实的DOM节点。
主要思想是，无论setState您在React事件处理程序或同步生命周期方法中进行多少次调用，它都将被批处理成一个更新, 最终只有一次重新渲染。
如果没有 Virtual DOM，就需要直接操作原生 DOM。在一个大型列表所有数据都变了的情况下，直接重置 innerHTML还算合理，但是，只有一行数据发生变化时，它也需要重置整个 innerHTML，这就造成了大量浪费。
Virtual DOM render + diff 显然比渲染 html 字符串要慢，但是它依然是纯 js 层面的计算，比起后面的 DOM 操作来说，依然便宜了太多。innerHTML 的总计算量不管是 js 计算还是 DOM 操作都是和整个界面的大小相关，但 Virtual DOM 的计算量只有 js 计算和界面大小相关，DOM 操作是和数据的变动量相关。
| 3. 如果元素更新，则创建新DOM。 | 3. 如果元素更新，则更新 JSX 。 |
| 4. DOM操作代价很高。 | |
| 5. 消耗的内存较多。 | 5. 很少的内存消耗。 |
MVVM 的性能也根据变动检测的实现原理有所不同：Angular 依赖于脏检查；Knockout/Vue/Avalon 采用了依赖收集。
Angular 最不效率的地方在于任何小变动都有的和 watcher 数量相关的性能代价，当所有数据都变了的时候，Angular更有效。依赖收集在初始化和数据变化的时候都需要重新收集依赖，这个代价在小量更新的时候几乎可以忽略，但在数据量庞大的时候也会产生一定的消耗。
在比较性能的时候，要分清楚初始渲染、小量数据更新、大量数据更新这些不同的场合。Virtual DOM、脏检查 MVVM、数据收集 MVVM 在不同场合各有不同的表现和不同的优化需求。
传统 diff 算法通过循环递归对节点进行依次对比，算法复杂度达到 O(n^3)，其中 n 是树中节点的总数。O(n^3) 意味着如果要展示1000个节点，就要依次执行上十亿次的比较， 这是无法满足现代前端性能要求的。
diff 算法主要包括几个步骤：
用 JS 对象的方式来表示 DOM 树的结构，然后根据这个对象构建出真实的 DOM 树，插到文档中。
当状态变更的时候，重新构造一棵新的对象树。然后用新的树和旧的树进行比较，记录两棵树的差异, 最后把所记录的差异应用到所构建的真正的DOM树上，视图更新。
React 通过分层求异的策略，对 tree diff 进行算法优化；
React 通过相同类生成相似树形结构，不同类生成不同树形结构的策略，对 component diff 进行算法优化；
React 对树进行分层比较，两棵树只会对同一层次的节点进行比较。
当发现节点已经不存在，则该节点及其子节点会被完全删除掉，不会进行进一步的比较。
这样只需要对树进行一次遍历，便能完成整个 DOM 树的比较。
当出现节点跨层级移动时，并不会出现移动操作，而是以该节点为根节点的树被重新创建，这是一种影响 React 性能的操作，因此 React 官方建议不要进行 DOM 节点跨层级的操作。
先进行树结构的层级比较，对同一个父节点下的所有子节点进行比较；
接着看节点是什么类型的，是组件就做 Component Diff;
注意：在开发组件时，保持稳定的 DOM 结构会有助于性能的提升。例如，可以通过 CSS 隐藏或显示节点，而不是真的移除或添加 DOM 节点。
如果是同一类型的组件，按照原策略继续比较 virtual DOM tree。
对于同一类型的组件，有可能其 Virtual DOM 没有任何变化，如果能够确切的知道这点那可以节省大量的 diff 运算时间。因此 React 允许用户通过 shouldComponentUpdate() 来判断该组件是否需要进行 diff。
对于两个不同类型但结构相似的组件，不会比较二者的结构，而且替换整个组件的所有内容。不同类型的 component 是很少存在相似 DOM tree 的机会，因此这种极端因素很难在实现开发过程中造成重大影响的。
INSERT_MARKUP，新的 component 类型不在老集合里， 即是全新的节点，需要对新节点执行插入操作。
MOVE_EXISTING，在老集合有新 component 类型，且 element 是可更新的类型，这种情况下需要做移动操作，可以复用以前的 DOM 节点。
REMOVE_NODE，老 component 类型，在新集合里也有，但对应的 element 不同则不能直接复用和更新，需要执行删除操作，或者老 component 不在新集合里的，也需要执行删除操作。
为了解决上述问题，React 引入了 key 属性, 对同一层级的同组子节点，添加唯一 key 进行区分。
当子元素拥有 key 时，React 使用 key 来匹配原有树上的子元素以及最新树上的子元素。如果有相同的节点，无需进行节点删除和创建，只需要将老集合中节点的位置进行移动，更新为新集合中节点的位置。
在开发过程中，尽量减少类似将最后一个节点移动到列表首部的操作，当节点数量过大或更新操作过于频繁时，在一定程度上会影响 React 的渲染性能。
key 不需要全局唯一，但在列表中需要保持唯一。
Key 应该具有稳定，可预测，以及列表内唯一的特质。不稳定的 key（比如通过
Math.random()生成的）会导致许多组件实例和 DOM 节点被不必要地重新创建，这可能导致性能下降和子组件中的状态丢失。
1. 监听数据变化的实现原理不同
Vue通过 getter/setter以及一些函数的劫持，能精确知道数据变化。
React默认是通过比较引用的方式（diff）进行的，如果不优化可能导致大量不必要的VDOM的重新渲染。
Vue1.0中可以实现两种双向绑定：父子组件之间props可以双向绑定；组件与DOM之间可以通过v-model双向绑定。
Vue2.x中父子组件之间不能双向绑定了（但是提供了一个语法糖自动帮你通过事件的方式修改)。
React一直不支持双向绑定，提倡的是单向数据流，称之为onChange/setState()模式。
Vue组合不同功能的方式是通过mixin，Vue中组件是一个被包装的函数，并不简单的就是我们定义组件的时候传入的对象或者函数。
React组合不同功能的方式是通过HoC(高阶组件）。
4. 模板渲染方式的不同
模板的语法不同，React是通过JSX渲染模板， Vue是通过一种拓展的HTML语法进行渲染。
模板的原理不同，React通过原生JS实现模板中的常见语法，比如插值，条件，循环等。而Vue是在和组件JS代码分离的单独的模板中，通过指令来实现的，比如 v-if 。
举个例子，说明React的好处：react中render函数是支持闭包特性的，所以我们import的组件在render中可以直接调用。但是在Vue中，由于模板中使用的数据都必须挂在 this 上进行一次中转，所以我们import 一个组件完了之后，还需要在 components 中再声明下。
Vue可以更快地计算出Virtual DOM的差异，这是由于它会跟踪每一个组件的依赖关系，不需要重新渲染整个组件树。
React当状态被改变时，全部子组件都会重新渲染。通过shouldComponentUpdate这个生命周期方法可以进行控制，但Vue将此视为默认的优化。
Vue本质是MVVM框架，由MVC发展而来；
React是前端组件化框架，由后端组件化发展而来。
CDN是一组分布在多个不同地理位置的 Web 服务器。当服务器离用户越远时，延迟越高。
头部内联的样式和脚本会阻塞页面的渲染，样式放在头部并使用link方式引入，脚本放在尾部并使用异步方式加载
压缩文件可以减少文件下载时间。
响应式图片：浏览器根据屏幕大小自动加载合适的图片。
降低图片质量：方法有两种，一是通过 webpack 插件 image-webpack-loader，二是通过在线网站进行压缩。
降低 CSS 选择器的复杂性
用 JavaScript 修改样式时，最好不要直接写样式，而是替换 class 来改变样式。
如果要对 DOM 元素执行一系列操作，可以将 DOM 元素脱离文档流，修改完成后，再将它带回文档。推荐使用隐藏元素（display:none）或文档碎片（DocumentFragement），都能很好的实现这个方案。
window.requestAnimationFrame() 告诉浏览器——你希望执行一个动画，并且要求浏览器在下次重绘之前调用指定的回调函数更新动画。该方法需要传入一个回调函数作为参数，该回调函数会在浏览器下一次重绘之前执行
index.html 设置成 no-cache，这样每次请求的时候都会比对一下 index.html 文件有没变化，如果没变化就使用缓存，有变化就使用新的 index.html 文件。
前端代码使用 webpack 打包，根据文件内容生成对应的文件名，每次重新打包时只有内容发生了变化，文件名才会发生变化。
max-age: 设置缓存存储的最大周期，超过这个时间缓存被认为过期(单位秒)。在这个时间前，浏览器读取文件不会发出新请求，而是直接使用缓存。
指定 no-cache 表示客户端可以缓存资源，每次使用缓存资源前都必须重新验证其有效性
建立TCP连接（三次握手）；
关闭TCP连接（四次握手）；
1. DNS域名解析：拿到服务器ip
客户端收到你输入的域名地址后，它首先去找本地的hosts文件，检查在该文件中是否有相应的域名、IP对应关系，如果有，则向其IP地址发送请求，如果没有，再去找DNS服务器。
2. 建立TCP链接：客户端链接服务器
TCP提供了一种可靠、面向连接、字节流、传输层的服务。对于客户端与服务器的TCP链接，必然要说的就是『三次握手』。“3次握手”的作用就是双方都能明确自己和对方的收、发能力是正常的。
客户端发送一个带有SYN标志的数据包给服务端，服务端收到后，回传一个带有SYN/ACK标志的数据包以示传达确认信息，最后客户端再回传一个带ACK标志的数据包，代表握手结束，连接成功。
SYN —— 用于初如化一个连接的序列号。
ACK —— 确认，使得确认号有效。
RST —— 重置连接。
FIN —— 该报文段的发送方已经结束向对方发送数据。
客户端：“你好，在家不。” -- SYN
客户端：“好嘞。” -- ACK
6. 关闭TCP连接（需要4次握手）
为了避免服务器与客户端双方的资源占用和损耗，当双方没有请求或响应传递时，任意一方都可以发起关闭请求。
关闭连接时，服务器收到对方的FIN报文时，仅仅表示客户端不再发送数据了但是还能接收数据，而服务器也未必全部数据都发送给客户端，所以服务器可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。
客户端：“兄弟，我这边没数据要传了，咱关闭连接吧。” -- FIN + seq
服务端：“收到，我看看我这边有木有数据了。” -- ACK + seq + ack
服务端：“兄弟，我这边也没数据要传你了，咱可以关闭连接了。” - FIN + ACK + seq + ack
浏览器需要加载解析的不仅仅是HTML，还包括CSS、JS，以及还要加载图片、视频等其他媒体资源。
浏览器通过解析HTML，生成DOM树，解析CSS，生成CSSOM树，然后通过DOM树和CSSPOM树生成渲染树。渲染树与DOM树不同，渲染树中并没有head、display为none等不必显示的节点。
浏览器的解析过程并非是串连进行的，比如在解析CSS的同时，可以继续加载解析HTML，但在解析执行JS脚本时，会停止解析后续HTML，会出现阻塞问题。
根据渲染树布局，计算CSS样式，即每个节点在页面中的大小和位置等几何信息。HTML默认是流式布局的，CSS和js会打破这种布局，改变DOM的外观样式以及大小和位置。最后浏览器绘制各个节点，将页面展示给用户。
replaint：屏幕的一部分重画，不影响整体布局，比如某个CSS的背景色变了，但元素的几何尺寸和位置不变。reflow：意味着元素的几何尺寸变了，需要重新计算渲染树。
细说浏览器输入URL后发生了什么
浏览器输入 URL 后发生了什么？
路由是用来跟后端服务器进行交互的一种方式，通过不同的路径请求不同的资源。
路由这概念最开始是在后端出现, 在前后端不分离的时期, 由后端来控制路由, 服务器接收客户端的请求,解析对应的url路径, 并返回对应的页面/资源。
在Ajax没有出现时期，大多数的网页都是通过直接返回 HTML，用户的每次更新操作都需要重新刷新页面，及其影响交互体验。为了解决这个问题，提出了Ajax(异步加载方案), 有了 Ajax 后，用户交互就不用每次都刷新页面。后来出现SPA单页应用。
SPA 中用户的交互是通过 JS 改变 HTML 内容来实现的，页面本身的 url 并没有变化，这导致了两个问题：
SPA 无法记住用户的操作记录，无论是刷新、前进还是后退，都无法展示用户真实的期望内容。
SPA 中虽然由于业务的不同会有多种页面展示形式，但只有一个 url，对 SEO 不友好，不方便搜索引擎进行收录。
前端路由就是为了解决上述问题而出现的。
前端路由的实现实际上是检测 url 的变化，截获 url 地址，解析来匹配路由规则。有下面两种实现方式：
hash 就是指 url 后的 # 号以及后面的字符。 #后面 hash 值的变化，并不会导致浏览器向服务器发出请求，浏览器不发请求，也就不会刷新页面。
在 HTML5 之前，浏览器就已经有了 history 对象。但在早期的 history 中只能用于多页面的跳转：
| 直接使用，无需服务端配合处理。 |
Babel是代码转换器，比如将ES6转成ES5，或者将JSX转成JS等。借助Babel，开发者可以提前用上新的JS特性。
实现Babel代码转换功能的核心，就是Babel插件（plugin）。Babel插件一般尽可能拆成小的力度，开发者可以按需引进, 既提高了性能，也提高了扩展性。比如对ES6转ES5的功能，Babel官方拆成了20+个插件。开发者想要体验ES6的箭头函数特性，那只需要引入transform-es2015-arrow-functions插件就可以，而不是加载ES6全家桶。
可以同时使用多个Plugin和Preset，此时，它们的执行顺序非常重要。
多个Plugin，按照声明次序顺序执行。
多个Preset，按照声明次序逆序执行。
比如.babelrc配置如下，那么执行的顺序为：
为了进一步提升网站性能，会把静态资源和动态网页分集群部署，静态资源会被部署到CDN节点上，网页中引用的资源也会变成对应的部署路径。当需要更新静态资源的时候，同时也会更新html中的引用。
如果同时改了页面结构和样式，也更新了静态资源对应的url地址，现在要发布代码上线，是先上线页面，还是先上线静态资源？
先部署页面，再部署资源：在二者部署的时间间隔内，如果有用户访问页面，就会在新的页面结构中加载旧的资源，并且把这个旧版本的资源当做新版本缓存起来，其结果就是：用户访问到了一个样式错乱的页面，除非手动刷新，否则在资源缓存过期之前，页面会一直执行错误。
先部署资源，再部署页面：在部署时间间隔之内，有旧版本资源本地缓存的用户访问网站，由于请求的页面是旧版本的，资源引用没有改变，浏览器将直接使用本地缓存，这种情况下页面展现正常；但没有本地缓存或者缓存过期的用户访问网站，就会出现旧版本页面加载新版本资源的情况，导致页面执行错误，但当页面完成部署，这部分用户再次访问页面又会恢复正常了。
这个奇葩问题，起源于资源的 覆盖式发布，用 待发布资源 覆盖 已发布资源，就有这种问题。
解决它也好办，就是实现 非覆盖式发布。用文件的摘要信息来对资源文件进行重命名，把摘要信息放到资源文件发布路径中，这样，内容有修改的资源就变成了一个新的文件发布到线上，不会覆盖已有的资源文件。
上线过程中，先全量部署静态资源，再灰度部署页面，整个问题就比较完美的解决了。
大公司的静态资源优化方案，基本上要实现这么几个东西：
配置超长时间的本地缓存 —— 节省带宽，提高性能
采用内容摘要作为缓存更新依据 —— 精确的缓存控制
静态资源CDN部署 —— 优化网络请求
更改资源发布路径实现非覆盖式发布 —— 平滑升级
