作为一名JS的粉忠实粉丝，虽然JS并没有JAVA的生态圈这么大，但是JavaScript从客户端脚本程序跻身服务器端，这让我们要重视一下它，JavaScript它在慢慢崛起，我们要换一种眼光去学习它。
Node.js是什么？
Node.js本质上是一个JavaScript的运行环境。
基于Google的V8引擎，实际上，是从Chrome上抠下的V8引擎并加以封装的一个执行环境。
我们去官网下载包，傻瓜式安装。
Node下载官网：https://nodejs.org/en/download/
在命令行输入node 就能运行javaScript脚本。
Node.js的优势？为什么脚本语言JavaScript能作为服务器语言？
优点 1 Node.js有超强的高并发能力
Node.js的首发目标，是提供一种简单的，用语创建高性能服务器及在该服务器中运行各种应用程序的开发工具。
相对于Java，PHP或者.net 等经典服务器端语言中，Node.js正像一个年轻力胜的小伙子，Java语言会为每一个客户端创建一个新的线程，而每一个客户端连接创建一个线程，需要耗费2MB的内存。也就是说。理论上一个8GB的服务器可以同时连接用户数为4000个左右，要存在高并发支持更多的用户，必须要额外增加服务器。
Node.js不为每个客户连接创建一个新的线程，而仅仅使用一个线程。
这就是Node基于单线程（只有一个主线程去接请求，给响应）
那这不是更慢吗？事实上，并不是这样。
Node.js当接收到一个用户连接，就会触发一个内部事件。通过事先定义好的函数，达到响应用户的行为。Node.js主线程并不关心程序要走什么流程，实际上，有另外的工作线程去帮Node主线程去存取文件，读数据库，当工作线程读取到文件数据，或数据库里面的数据，就会把回调函数返回给Node主线程去执行，例如 把找到的数据传回客户端，关闭连接一些操作。（这就是Node非阻塞I/O，基于事件驱动）。
下面附上我画的一张图（如有不恰当之处请见谅哈）
这时候我们脑袋里面应该有个雏形，就是——Node.js主线程一直在接收请求和响应请求这个活里面倒腾，这样它就可以不停地接收多个客户端发过来的请求，它不用傻傻去等待IO操作，IO工作线程找到了数据，就会触发事件回调函数告诉主线程数据已经拿到了，这时候主线就执行回调函数，把数据返回给客户端。
理论上，一个8G内存的服务器，可以同时容纳3到4万用户的连接。
这就是Node的闪光之处（单线程，非阻塞IO，事件驱动）
优点 2 Node用的就是JavaScript的语法
Node.JS 基于 javaScript 的 V8引擎，也就是说只要会JS的语法，就能用于后端开发，但是Node官方推荐用ECMA Script6（ES6）语法 。
Node打破了过去JavaScript只能在浏览器运行的局面，让前后端编程环境统一，这样就大大降低了开发成本。(这一点对前端开发人员非常友好，JS能做的东西越来越多，前端发展就越来越快)
优点 3 Node.JS 出现促成前端工程化思想
前端最近几年发展迅速，Node.js起到不可替代的作用。
Node.js不仅仅是运行环境，也是一门脱胎换骨全新的JavaScript语言，它容纳了JS语法基础，还加入一些内部模块
如：
http用来处理请求响应的模块
fs 用来读取文件的模块
url 用来解析请求数据等等
const http = require('http')Node.js还集成了 Npm 包管理工具，让我们可以很方便的通过命令行就能下载我们项目依赖的包
如：
npm install jquery
npm install -g webpack
npm install -g create-react-app 等等
同样,只要在项目里面进行引入就能使用
const Jquery = require('jquery');Node 还支持 自定义模块语法 ↓↓
const app =()=>{
//模块代码
}
module.exports = app;
const app = require('module/app.js'); //引入自定义模块Node.js 在某种层面上影响着前端开发的模式。让前端工程模块化，开发迅速，降低代码耦合度，可维护性大大增强。
Node.js适合做什么？
下面列举几个Node.js应用场景
虽然以上列举这么多Node.js的优点，但是没有一门语言是没有缺点，Node也不例外。只能是一门语言适用于什么场景和领域而已。
下面说说Node.js不适用的场景（加个大标题↓↓↓）
Node不适应的场景
①CPU计算密集型的程序
在Node.js 0.8 版本之前，Node.js 不支持多线程。当然，这是一种设计哲学问题，因为Node.js的开发者和支持者坚信单线程和事件驱动的异步式编程比传统的多线程编程运行效率更高。但事实上多线程可以达到同样的吞吐量，尽管可能开销不小，但不必为多核环境进行特殊的配置。相比之下，Node.js 由于其单线程性的特性，必须通过多进程的方法才能充分利用多核资源。
理想情况下，Node.js单线程在执行的过程中会将一个CPU核心完全占满，所有的请求必须等待当前请求处理完毕以后进入事件循环才能响应。如果一个应用是计算密集型的，那么除非你手动将它拆散，否则请求响应延迟将会相当大。例如，某个事件的回调函数中要进行复杂的计算，占用CPU 200毫秒，那么事件循环中所有的请求都要等待200毫秒。为了提高响应速度，你唯一的办法就是把这个计算密集的部分拆成若干个逻辑，这给编程带来了额外的复杂性。即使这样，系统的总吞吐量和总响应延迟也不会降低，只是调度稍微公平了一些。不过好在真正的Web 服务器中，很少会有计算密集的部分，如果真的有，那么它不应该被实现为即时的响应。正确的方式是给用户一个提示，说服务器正在处理中，完成后会通知用户，然后交给服务器的其他进程甚至其他专职的服务器来做这件事。
②单用户多任务型应用
前面我们讨论的通常都是服务器端编程，其中一个假设就是用户数量很多。但如果面对的是单用户，譬如本地的命令行工具或者图形界面，那么所谓的大量并发请求就不存在了。于是另一个恐怖的问题出现了，尽管是单用户，却不一定是单任务。例如给用户提供界面的同时后台在进行某个计算，为了让用户界面不出现阻塞状态，你不得不开启多线程或多进程。而Node.js 线程或进程之间的通信到目前为止还很不便，因为它根本没有锁，因而号称不会死锁。Node.js 的多进程往往是在执行同一任务，通过多进程利用多处理器的资源，但遇到多进程相互协作时，就显得捉襟见肘了。
③逻辑十分复杂的事务
Node.js 的控制流不是线性的，它被一个个事件拆散，但人的思维却是线性的，当你试图转换思维来迎合语言或编译器时，就不得不作出牺牲。举例来说，你要实现一个这样的逻辑：从银行取钱，拿钱去购买某个虚拟商品，买完以后加入库存数据库，这中间的任何一步都可能会涉及数十次的I/O操作，而且任何一次操作失败以后都要进行回滚操作。这个过程是线性的，已经很复杂了，如果要拆分为非线性的逻辑，那么其复杂程度很可能就达到无法维护的地步了。Node.js更善于处理那些逻辑简单但访问频繁的任务，而不适合完成逻辑十分复杂的工作。
“好了，以上就是我总结了Node.js。不说了，写了很久了，去撸代码了。”