接触Node，提得最多的可能就是回调，异步非阻塞处理，思前想后，JavaScript从前端语言过渡到服务器端，最大的劣势可能就是线程，当然这方面的不足现在也被慢慢弥补起来了（很多第三方的npm包可供下载），而在初期时，其语言的执行思想也是偏向多线程的，于是用了一个非常巧妙的方法：事件驱动。
Node.Js使用事件驱动模型，当web server接收到请求，就把它关闭然后进行处理，然后去服务下一个web请求。当这个请求完成，它被放回处理队列，当到达队列开头，这个结果被返回给用户。这个模型非常高效可扩展性非常强，因为webserver一直接受请求而不等待任何读写操作。（这也被称之为非阻塞式IO或者事件驱动IO）
这边引用之前看过的一篇博客上的图及setTimeout的说明
这边就要借用setTimeout()函数来说明Node的事件驱动机制，首先运行下面一段函数
console.log("aaaa");
for(i=1;i<3;i++){
setTimeout(function(){console.log(i)},0)
}
console.log("bbbb");
运行结果：
比较怪异的是console完aaaa之后并没有立即console setTimeout里的函数，当然如果这里去掉setTimeout改为console结果还是会如我们想象的一样，当然我们要讲的是事件驱动，所以这边用一个setTimeout（fuc，0）来表示立即执行。而我们看到了setTimeout执行落在了正常事件的最后，之前看的一篇博客，博主写的是setTimeout函数如果置零，也不会立即执行，因为HTML5默认规范对于setTimeout函数有2ms的延迟，那会不会是因为这2ms的延迟致使输出延时了呢，于是我们改进下代码console
console.log("aaaa");
for(i=1;i<3;i++){
setTimeout(function(){console.log(i)},500);console.log("bbbb");
}
for(n=1;n<4;n++){
console.error(n);
}
console.log("cccc");
运行结果：
设置了500ms延迟，之后也用了for循环做了3s的阻塞，但是输出结果还是延时，所以setTimeout执行的延时并非我们想象的那样，而结合nodeJs的事件代理，我们得知当js运行到setTimeout时，实际上为了不造成阻塞，会将setTimeout时间扔到浏览器的时间队列中，当函数从头到尾执行完后，再抛出我们setTimeout的输出结果