node.js 有什么用，它的出现解决了什么问题？优缺点在哪？
Node.js 是一个 JavaScript 运行时环境。听起来还不错，不过这究竟意味着什么？它又是如何运作的？
Node 运行时环境包含执行 JavaScript 程序所需要的一切。
JavaScript 原来是只能在浏览器中运行的，当把它扩展成为可以在你的计算机上作为独立的程序运行时，Node.js 就出现了。
现在你可以用 JavaScript 做更多的事情，而不仅仅是用在网站的互动和特效上。
你 Chrome 浏览器中的 JavaScript 和 Node.js 都在 V8 引擎上运行。该引擎将你的 JavaScript 代码转换为更快的机器代码。机器代码是低级代码，计算机可以直接运行而无需先解释它。
为什么要用node.js
①你的 Chrome 浏览器中的 JavaScript 和 Node.js 都在 V8 引擎上运行。该引擎将你的 JavaScript 代码转换为更快的机器代码。机器代码是低级代码，计算机可以直接运行而无需先解释它。
②Node.js 使用事件驱动的非阻塞 I/O（输入与输出）模型，轻量且高效。
③Node.js 的包生态系统 npm 是世界上最大的开源库生态系统。
**NPM:*社区所构建的库，它能解决你的大多数的常规问题。 npm（Node package manager)）中有很多可以用在你的程序中包，可以使你的开发更快更有效。
node.js的特点--------------
node.js采用事件驱动，异步编程，为网络服务而设计
node.js的特点，可以根据程序的需要进行取舍
0.：高并发(最重要的优点)
适合环境：适合I/O密集型应用
缺点:不适合CPU密集型应用,带来 的主要挑战是由于js单线程运行事件过长，将会导致CPU不能释放，是的后续I/O无法发起
解决方案：分解大型计算任务为多个小型的任务，是的运算能够适时释放，不阻塞I/O调用的发起
1，可靠性低
2，高性能
3，单线程
4，异步事件驱动
5，非阻塞I/O
6，轻量高效
**可靠性低：**一个线程（系统·环节）出错，整个系统都会崩
解决方案：开多个进程，绑定多个端口
什么是事件驱动：首先，解释下“事件驱动”这个概念。所谓事件驱动，是指在持续事务管理过程中，进行决策的一种策略，即跟随当前时间点上出现的事件，调动可用资源，执行相关任务，使不断出现的问题得以解决，防止事务堆积。
总结（事件循环+回调通知）
Nodejs设计思想中以事件驱动为核心，事件驱动在于异步回调，他提供的大多数api都是基于事件的、异步的风格。而事件驱动的优势在于充分利用系统资源，执行代码无须阻塞等待某种操作完成，有限的资源用于其他任务。事件驱动机制是通过内部单线程高效率地维护事件循环队列来实现的，没有多线程的资源占用和上下文的切换。
**I/O流和非I/O：**传统的服务器语言大多是多线程、阻塞式 I/O。这也是 Node 与众不同的地方，对于传统的服务器语言，在与用户建立连接时，每一个连接都是一个线程。 当有十万个用户连接时，服务器上就会有十万个线程。而阻塞式 I/O 是指，当一个线程在执行 I/O 操作时，这个线程会阻塞，等待 I/O 操作完成后继续执行。
进程给CPU传达任我后，继续处理后续的操作，隔断时间再来询问之前的操作是否完成。这样的过程其实也叫轮询。
单线程： Nodejs跟Nginx一样都是单线程为基础的，这里的单线程指主线程为单线程，所有的阻塞的全部放入一个线程池中，然后主线程通过队列的方式跟线程池来协作。我们写js部分不需要关心线程的问题，简单了解就可以了，主要由一堆callback回调构成的，然后主线程在循环过在适当场合调用。
**性能出众：**底层选择用c++和v8来实现的，上面第一点讲到过，nodejs的事件驱动机制，这意味着面对大规模的http请求，nodejs是凭借事件驱动来完成的，性能部分是不用担心的，并且很出色。
Nodejs应用场景：
适合I/O密集型的应用，如在线多人聊天，多人在线小游戏，实时新闻，博客，微博之类的。
不适合的场景有：cpu密集型的应用，如计算圆周率，视频解码等业务场景较多的。
什么是I/O密集： IO密集型指的是系统的CPU性能相对硬盘、内存要好很多，此时，系统运作，大部分的状况是CPU在等I/O (硬盘/内存) 的读/写操作，此时CPU Loading并不高。
I/O bound的程序一般在达到性能极限时，CPU占用率仍然较低。这可能是因为任务本身需要大量I/O操作，而pipeline做得不是很好，没有充分利用处理器能力。
CPU密集型 vs IO密集型
我们可以把任务分为计算密集型和IO密集型。
计算密集型任务的特点是要进行大量的计算，消耗CPU资源，比如计算圆周率、对视频进行高清解码等等，全靠CPU的运算能力。这种计算密集型任务虽然也可以用多任务完成，但是任务越多，花在任务切换的时间就越多，CPU执行任务的效率就越低，所以，要最高效地利用CPU，计算密集型任务同时进行的数量应当等于CPU的核心数。
计算密集型任务由于主要消耗CPU资源，因此，代码运行效率至关重要。Python这样的脚本语言运行效率很低，完全不适合计算密集型任务。对于计算密集型任务，最好用C语言编写。
第二种任务的类型是IO密集型，涉及到网络、磁盘IO的任务都是IO密集型任务，这类任务的特点是CPU消耗很少，任务的大部分时间都在等待IO操作完成（因为IO的速度远远低于CPU和内存的速度）。对于IO密集型任务，任务越多，CPU效率越高，但也有一个限度。常见的大部分任务都是IO密集型任务，比如Web应用。
IO密集型任务执行期间，99%的时间都花在IO上，花在CPU上的时间很少，因此，用运行速度极快的C语言替换用Python这样运行速度极低的脚本语言，完全无法提升运行效率。对于IO密集型任务，最合适的语言就是开发效率最高（代码量最少）的语言，脚本语言是首选，C语言最差。
总之，计算密集型程序适合C语言多线程，I/O密集型适合脚本语言开发的多线程。
什么是cpu密集： PU密集型也叫计算密集型，指的是系统的硬盘、内存性能相对CPU要好很多，此时，系统运作大部分的状况是CPU Loading 100%，CPU要读/写I/O(硬盘/内存)，I/O在很短的时间就可以完成，而CPU还有许多运算要处理，CPU Loading很高。
在多重程序系统中，大部份时间用来做计算、逻辑判断等CPU动作的程序称之CPU bound。例如一个计算圆周率至小数点一千位以下的程序，在执行的过程当中绝大部份时间用在三角函数和开根号的计算，便是属于CPU bound的程序。
CPU bound的程序一般而言CPU占用率相当高。这可能是因为任务本身不太需要访问I/O设备，也可能是因为程序是多线程实现因此屏蔽掉了等待I/O的时间。
总结：（读写频繁 和计算频繁）。。。。
简单说说（MVVM、MVP、MVC）的区别
①View 传送指令到 Controller
②Controller 完成业务逻辑后，要求 Model 改变状态
③Model 将新的数据发送到 View，用户得到反馈
①各部分之间的通信，都是双向的。
②View 与 Model 不发生联系，都通过 Presenter 传递。
③View 非常薄，不部署任何业务逻辑，称为"被动视图"（Passive View），即没有任何主动性，而 Presenter非常厚，所有逻辑都部署在那里。所有通信都是单向的。
唯一的区别是，它采用双向绑定（data-binding）：View的变动，自动反映在 ViewModel，反之亦然。
这里面使用的设计模式有：观察者模式（发布订阅模式）、代理模式、工厂模式、单例模式。
双向绑定
在 MVVM 中，UI 是通过数据驱动的，数据一旦改变就会相应的刷新对应的 UI，UI 如果改变，也会改变对应的数据。这种方式就可以在业务处理中只关心数据的流转，而无需直接和页面打交道。ViewModel 只关心数据和业务的处理，不关心 View 如何处理数据，在这种情况下，View 和 Model 都可以独立出来，任何一方改变了也不一定需要改变另一方，并且可以将一些可复用的逻辑放在一个 ViewModel 中，让多个 View 复用这个 ViewModel。
Raect发展史，优缺点，为什么要用
React诞生的原因
React是Facebook开发的一款的JS库，那么Facebook为什么要创造React？
Facebook认为MVC无法满足他们的扩展需求，由于他们非常巨大的代码库和庞大的组织，使得MVC很快变得复杂，每当需要添加一项新功能或者特性时，系统的复杂就成级数的增长，致使代码变得脆弱而不可预测，结果导致他们的MVC正在土崩瓦解。认为MVC不适合大规模的应用。当系统中有很多模型和相应的视图时，其复杂度就会迅速扩大，非常难以理解和调试，特别是模型和视图可能存在双向数据流动。
解决这个问题需要“以某种方式组织代码，使其更加可预测”，这通过Flux和React已经完成
Flux是一个系统架构，用于推进应用中的数据单向流动。**React是一个JavaScript框架，**用于构建“可预期的”和声明式的”Web用户界面”，它已经使Facebook更快地开发Web应用。
React特点：
1.简单的表述任意时间点应用应该呈现的样子，React就会自动管理UI界面更新当数据发生变化的时候
2.在数据发生改变时，React实际上仅仅更新了变化的一部分而已
React是关于构造可重用组件的，实际上，使用React时，我们做的更多的是构建组件。通过封装，使得代码复用，测试以及关注点分离更加容易。
创建React文档的四个原因：
1.React不是一个MVC框架，React是一个构造可组合式用户界面的库。它鼓励创建可重用的UI组件会随着时间而改变的数据。
2.React不使用模板
传统上，web应用UIs使用模板或者html指令构造。这些模板规定一套完整的抽象使你可以去构建你的UI
不同的是，React处理构建用户界面通过将他们分解为组件。这意味着，React使用一个真正的，全功能的编程语言去渲染视图。
3.响应式更新非常简单
在一个传统的JS应用中，需要考虑数据变化然后指示DOM做出变化，使其保持最新的。甚至AngularJS,提供一个声明式接口经由指令和数据绑定请求一个关联的函数去手动更新DOM节点。
React采用不同的方法，当组件第一次初始化时，render方法调用，为试图生成一个轻量级的表现。通过这个表现，产生一个标签字符串，然后插入文档中。当数据变化时，render方法再次被调用。为了尽可能有效的完成更新，我们比较值钱调用的render返回的值与新的值，然后产生一个最小的变更去应用DOM中。
render返回的数据既不是一个字符串也不是一个DOM结点。它是一个轻量级的类型，描述DOM应该是什么样子的。
4.HTML5仅仅是个开始
因为React有自己轻量级的文档表现，我们可以用它做一些很酷的事情
1.Facebook动态表格可以通过渲染取代HTML.
2.Instagram是一个’single page’网页应用完全由React和Backbone.Router构建的。设计者可以像通常一样使用JSX编写React代码。
3.我构建内部的应用雏形运行React在一个web工作站上，使用React去驱动本地ios视图通过一个Objective-C桥。
4.你可以运行React在服务器上，便于SEO、性能、代码分享和项目灵活性。
5.事件在全部现代浏览器(包括IE8)下表现一致性还有符合标准化，并且自动使用事件委派。
React的主要原理
Virtual DOM和虚拟DOM
传统的web应用中，操作DOM一般是直接更新操作的，但是我们知道DOM更新通常是比较昂贵的。而React为了尽可能减少对DOM的操作，提供了一种不同而有强大的方式来更新DOM，代替DOM直接操作。就是Virtual DOM,一个轻量级的虚拟DOM，就是React抽象出来的一个对象，描述DOM应该是什么样子，应该如何呈现。通过 这个Virtual DOM去更新更真实的DOM，而这个Virtual DOM管理真实的DOM更新。
为什么通过这多一层的Virtual DOM操作就能更快呢？ 这是因为React有个diff算法，更新Virtual DOM并不保证马上影响真实的DOM，React会等到事件循环结束，然后利用这个diff算法，通过当前新的dom表述与之前的作比较，计算出最小的步骤更新真实的DOM。
diff概念： setState被设计为一个异步的方法，目的是为了提升React底层的性能。假设我们短时间内连续变更3次state，React就会把这3次setState合并为一次setState，只做一次VDOM的比对，提高了整体的性能。
1.两个相同组件产生类似的的DOM结构，不同组件产生不同的DOM结构
2.对于同层次的一组子节点，他们可以通过唯一的id进行区分
在节点的同一位置前后输出了不同类型的节点，React直接删除前面的节点，然后创建并插入新的节点，删除节点就会彻底销毁该节点，如果该删除的节点下有子节点，那么这些子节点也会被完全删除，它们也不会被用户后面的比较
当React在同一个位置遇到不同的组件时，也是简单的销毁第一个组件，而把新创建的组件加上去。不同的组件一般会产生不一样的DOM结构，与其浪费时间去比较它们的结构，他们的结构基本上是不会等价的，还不如完全创建一个新的组件上去。
2.逐层次进行节点比较
在React中，树的算法很简单，两棵树只会对同层次的节点进行比较。把之前的树和修改之后的树进行节点同层次的比较，React对同一个父节点下所有的子节点进行比较。当发现节点已经不存在了，就会把这个节点和它的子节点完善删除掉，不会进行进一步的人比较，所以这样只要遍历一次树，就可以完成对DOM结构的比较。
React只会考虑同层节点位置的变换，对于不同层的节点，只有简单的删除和创建。当根节点发现子节点中的A不见了就会直接销毁A；而当D发现自己多了一个子节点，就会创建A作为子节点。
为了保持稳定的结构会有助于性能的提升，我们可以通过CSS隐藏或显示某个节点，而不是真正的移除或者添加DOM节点。
如果不设置这个li 的key值，会造成列表在更新时候的性能问题。React不能很高效的去更新这个列表。但是数组中必要用key。
Components 组件
在DOM树上的节点被称为元素，在这里则不同，Virtual DOM上称为commponent。Virtual DOM的节点就是一个完整抽象的组件，它是由commponents组成。
component 的使用在 React 里极为重要, 因为 components 的存在让计算 DOM diff 更高效。
优点
1、React速度很快
它并不直接对DOM进行操作，引入了一个叫做虚拟DOM的概念，安插在javascript逻辑和实际的DOM之间，性能好
2、跨浏览器兼容
虚拟DOM帮助我们解决了跨浏览器问题，它为我们提供了标准化的API，甚至在IE8中都是没问题的。
3、一切都是component：
代码更加模块化，重用代码更容易，可维护性高。
4、单向数据流
Flux是一个用于在JavaScript应用中创建单向数据层的架构，它随着React视图库的开发而被Facebook概念化。
5、同构、纯粹的javascript
因为搜索引擎的爬虫程序依赖的是服务端响应而不是JavaScript的执行，预渲染你的应用有助于搜索引擎优化。
缺点
问题一：ReactJS组件难以在复杂交互页面中复用
ReactJS中的最小复用单位是组件。ReactJS的组件比AngularJS的Controller和View 要轻量些。 每个组件只需要前端开发者提供一个 render 函数，把 props 和 state 映射成网页元素。
这样的轻量级组件在渲染简单静态页面时很好用， 但是如果页面有交互，就必须在组件间传递回调函数来处理事件。
问题二：ReactJS的虚拟DOM 算法又慢又不准
ReactJS的页面渲染算法是虚拟DOM差量算法。
开发者需要提供 render 函数，根据 props 和 state 生成虚拟 DOM。 然后 ReactJS 框架根据 render 返回的虚拟 DOM 创建相同结构的真实 DOM.
每当 state 更改时，ReacJS 框架重新调用 render 函数，获取新的虚拟 DOM 。 然后，框架会比较上次生成的虚拟 DOM 和新的虚拟 DOM 有哪些差异，然后把差异应用到真实DOM上。
这样做有两大缺点：
每次 state 更改，render 函数都要生成完整的虚拟 DOM. 哪怕 state 改动很小，render函数也会完整计算一遍。如果 render 函数很复杂，这个过程就白白浪费了很多计算资源。
ReactJS框架比较虚拟DOM差异的过程，既慢又容易出错。比如，假如你想要在某个
- 列表的顶部插入一项
- ，那么ReactJS框架会误以为你修改了
- 的每一项
- ，然后在尾部插入了一个
- 。
这是因为 ReactJS收到的新旧两个虚拟DOM之间相互独立，ReactJS并不知道数据源发生了什么操作，只能根据新旧两个虚拟DOM来猜测需要执行的操作。 自动的猜测算法既不准又慢，必须要前端开发者手动提供 key 属性、shouldComponentUpdate 方法、componentDidUpdate 方法或者 componentWillUpdate 等方法才能帮助 ReactJS 框架猜对。
问题三：ReactJS的HTML模板功能既不完备、也不健壮
ReactJS支持用JSX编写HTML模板。
理论上，前端工程师只要把静态HTML原型复制到JSX源文件中， 增加一些变量替换代码， 就能改造成动态页面。 理论上这种做法要比Cycle.js、Widok、ScalaTags等框架更适合复用设计师提供的HTML原型。
不幸的是，ReactJS对HTML的支持残缺不全。开发者必须手动把class和for属性替换成className和htmlFor，还要把内联的style样式从CSS语法改成JSON语法，代码才能运行。 这种开发方式下，前端工程师虽然可以把HTML原型复制粘贴到代码中，但还需要大量改造才能实际运行。 比Cycle.js、Widok、或者、ScalaTags省不了太多事。
问题四：ReactJS与服务器通信时需要复杂的异步编程
除此之外，ReactJS还提供了propTypes机制校验虚拟DOM的合法性。 然而，这一机制也漏洞百出。 即使指定了propTypes，ReactJS也不能在编译前提前发现错误。只有测试覆盖率很高的项目时才能在每个组件使用其他组件时进行校验。 即使测试覆盖率很高，propTypes仍旧不能检测出拼错的属性名，如果你把onClick写成了onclick， ReactJS就不会报错，往往导致开发者额外花费大量时间排查一个很简单的bug。
ReactJS从服务器加载数据时的架构可以看成MVVM(Model–View–ViewModel)模式。 前端工程师需要编写一个数据库访问层作为Model，把ReactJS的state当做ViewModel，而render当做View。 Model负责访问数据库并把数据设置到state(即View Model)上，可以用Promise和fetch API实现。 然后，render，即View，负责把View Model渲染到页面上。
在这整套流程中，前端程序员需要编写大量闭包组成的异步流程， 设置、访问状态的代码五零四散， 一不小心就会bug丛生，就算小心翼翼的处理各种异步事件，也会导致程序变得复杂，既难调试，又难维护。
VUE因为什么而出现，优缺点，适用于什么
1.什么是VUE
是一套构建用户界面的 渐进式框架。与其他重量级框架不同的是，Vue 采用自底向上增量开发的设计。Vue 的核心库只关注视图层，并且非常容易学习，非常容易与其它库或已有项目整合。另一方面，Vue 完全有能力驱动采用单文件组件和 Vue 生态系统支持的库开发的复杂单页应用。
Vue.js 的目标是通过尽可能简单的 API 实现响应的数据绑定和组合的视图组件。
2.VUE是什么（单页面应用）
Vue.js就是一个用于搭建类似于网页版知乎这种表单项繁多，且内容需要根据用户的操作进行修改的网页版应用。单页应用一般指的就是一个页面就是应用，当然也可以是一个子应用，比如说知乎的一个页面就可以视为一个子应用。单页应用程序中一般交互处理非常多，而且页面中的内容需要根据用户的操作动态变化。
3.为什么不用JQ写，要用VUE，区别
讲到JQuery，就不得不说到JavaScript的DOM操作了。如果你用JQuery来开发一个知乎，那么你就需要用JQuery中的各种DOM操作方法去操作HTML的DOM结构了。
现在我们把一个网页应用抽象一下，那么HTML中的DOM其实就是视图，一个网页就是通过DOM的组合与嵌套，形成了最基本的视图结构，再通过CSS的修饰，在基本的视图结构上“化妆”让他们看起来更加美观。最后涉及到交互部分，就需要用到JavaScript来接受用户的交互请求，并且通过事件机制来响应用户的交互操作，并且在事件的处理函数中进行各种数据的修改，比如说修改某个DOM中的innerHTML或者innerText部分。
我们把HTML中的DOM就可以与其他的部分独立开来划分出一个层次，这个层次就叫做视图层。
Vue 的核心库只关注视图层
我们为什么要把视图层抽取出来并且单独去关注它呢？
因为在像知乎这种页面元素非常多，结构很庞大的网页中，数据和视图如果全部混杂在一起，像传统开发一样全部混合在HTML中，那么要对它们进行处理会十分的费劲，并且如果其中有几个结构之间存在藕断丝连的关系，那么会导致代码上出现更大的问题，这什么问题呢？
你是否还记得你当初写JQuery的时候，有KaTeX parse error: Expected 'EOF', got '#' at position 3: ('#̲xxx').parent().…(’#xxx’).parent().parent().parent()可能就会变成
$(’#xxx’).parent().parent().parent().parent().parent()了。
这还不算什么，等以后产品迭代越来越快，修改越来越多，而且页面中类似的关联和嵌套DOM元素不止一个，那么修改起来将非常费劲。而且JQuery选择器查找页面元素以及DOM操作本身也是有性能损失的，可能到时候打开这个页面，会变得越来越卡，而你却无从下手。
当你在编写项目的时候遇到了这种问题，你一定会抱怨，为什么世上会有HTML这种像盗梦空间一样的需要无数div嵌套才能做出页面的语言，为什么当初学JQuery看中的是它简洁的DOM操作，现在却一点也不觉得它有多简洁，难道我学的是假的JQuery？为什么写个代码这么难，你想砸电脑，你想一键盘拍在产品狗的脑袋上，责怪他天天改需求才让你原本花清香茶清味的代码变得如此又臭又长。
5.Vue.js为什么能让基于网页的前端应用程序开发起来这么方便？
因为Vue.js有声明式，响应式的数据绑定，与组件化的开发，并且还使用了Virtual DOM这个看名字就觉得高大上的技术。
可是这些名词都是啥？
①什么是响应式数据绑定：v-model同步改变数据
②什么是组件化开发：说PHP的Smarty或者Java的JSP等等。
但是现在我们做单页应用，页面交互和结构十分复杂，一个页面上就有许许多多的模块需要编写，而且往往一个模块的代码量和工作量就非常庞大，如果还按照原先的方法来开发，那么会累死人。而且遇到以后的产品需求变更，修改起来也非常麻烦，生怕动了其中一个div之后，其他div跟着雪崩，整个页面全部乱套，或者由于JavaScript的事件冒泡机制，导致修改一些内层的DOM事件处理函数之后，出现各种莫名其妙的诡异BUG。
在面向对象编程中，我们可以使用面向对象的思想将各种模块打包成类或者把一个大的业务模块拆分成更多更小的几个类。在面向过程编程中，我们也可以把一些大功能拆分成许多函数，然后分配给不同的人来开发。
在前端应用，我们是否也可以像编程一样把模块封装呢？这就引入了组件化开发的思想。
Vue.js通过组件，把一个单页应用中的各种模块拆分到一个一个单独的组件（component）中，我们只要先在父级应用中写好各种组件标签（占坑），并且在组件标签中写好要传入组件的参数（就像给函数传入参数一样，这个参数叫做组件的属性），然后再分别写好各种组件的实现（填坑），然后整个应用就算做完了。
6.Vuex和Vue-route，它们又是什么？
Vuex是vue的一个状态管理器。用于集中管理一个单页应用程序中的各种状态。
Vue-route是vue的一个前端路由器，这个路由器不是我们上网用的路由器，而是一个管理请求入口和页面映射关系的东西。它可以实现对页面局部进行无刷新的替换，让用户感觉就像切换到了网页一样。
7.Vue-resource和Axios，它们又是什么？
我们在传统的前后端不分离的开发中，后端直接把数据通过模版引擎拼接进了返回的HTML中。而现在做单页应用程序属于前后端分离开发，那么这个单页应用程序中的数据就得通过ajax的方式获取，也要通过ajax的方式提交到后端。
在传统开发中我们都是通过xmlhttprequest手动操作，或者通过JQuery的ajax方法来进行数据提交获取。
vue.js本身没有封装ajax操作库，所以我们要通过Vue-resource和Axios来进行ajax操作，而因为种种原因，现在vue.js2.0已经将axios作为官方推荐的ajax库了。
优点
1.VUE的特性
1、轻量级的框架
2、双向数据绑定
3、指令
4、插件化
2.vue的优点
1、简单易用
2、灵活渐进式
3、轻量高效
（3-1）、压索之后20KB大小
（3-2） 、虚拟DOM
3、组件化
组件化优点
提高开发效率
方便重复使用
简化调试步骤
提升整个项目的可维护性
便于协同开发
缺点
1、Vue 不缺入门教程，可是很缺乏高阶教程与文档。同样的还有书籍。
2、VUE不支持IE8
3、生态环境差不如angular和react
4、社区不大
如果有问题可以读源码。功能仅限于 view 层，Ajax 等功能需要额外
的库。对开发人员要求较高。开发的话，需要 webpack，不然很难用，最好配合 es6。不过Vue-cli把webpakc也隔离的差不多了
最后React和VUE的区别
模板渲染方式不同
前面说了，Vue和React的模板有所区别，React是通过JSX来渲染模板，而Vue是通过扩展的HTML来进行模板的渲染。React通过原生JS实现模板中的常见语法，比如说条件啊、循环啊、三元运算符啊等，都是通过JS语法实现。而Vue是在和组件代码分离的单独模板中，通过指令v-if、v-for等实现。
这里react比较好点，比如我们要引用一个组件，react直接import 引入，然后可以直接在render中调用了，但是！！vue需要import之后，还要在components里去声明，才能用，好气哦 ～
数据流程
VUE: Parent > (Props) > Child > (m-modle) >< DOM
React: Parent > (Props) > Child > (state) > DOM
我们可以看到，在Vue2.x中，只能parent -> Child <-> DOM的形式，而React只能单向传递，React一直提倡的是单向数据流，数据主要从父节点传递到子节点（通过props）。如果顶层（父级）的某个props改变了，React会重渲染所有的子节点。我们只能通过setState来改变状态。
还有一些以后的事情，以后在说吧
文章