对于面试中，大家可能对于面试官提问的场景题都暗暗发怵，感觉很难招架，其实这也是有迹可循的。
可以分一下两点：
（1）面试官会出哪些场景题
（2）场景题解答方法
面试官会出哪些场景题
之前也讲过，你和面试官的唯一纽带就是你的简历。
他认为只要你简历上的东西你都会了，就可以给你发offer。所以一切的出题点都是围绕你的简历呢。
那有人会问，这场景题，感觉和我简历毫不搭边啊，丝毫不知道咋准备啊。
场景题其实就是围绕着两个东西延申:
(1)对你技术栈上技能点的延申
（2）对你项目的深度拓展
对你技术栈技能点的延申，比如你写了个熟悉线程池，然后面试官让你介绍了，但是你介绍的很简单。这个时候面试官，就会设想不同的场景，问你解决方法了。（场景题这不就来了嘛）
对你项目的深度拓展，比如你是一个后端的项目，上来就是一个注册登录功能，面试官都看腻了。然后针对登录就会设想不同的场景对你进行拷打了。比如同一个账户不同设备同时登录怎么办等等。
所以，场景题其实都是有迹可循的，大家没事的时候对照自己的简历多想想，多找找极端情况的bug。
多自己总结延申延申，一边是自己总结延申，一边是在面试中面试官问的问题总结延申，这样不久，就可以根据你的简历整理出来一份专属于你简历的场景题了，这样面试官问的几乎就在上面了，还怕什么啊
场景题解答方法
在 Node.js 中，客户端请求建立连接，提交数据等行为，会触发相应的事件。在 Node.js 中，在一个时刻，只能执行一个事件回调函数，但是在执行一个事件回调函数的中途，又有其他事件产生，可以转而处理其他事件（比如，又有新用户连接了），然后返回继续执行原事件的回调函数，这种处理机制，称为“事件环”机制。
Node.js 底层是 C++（V8也是C++写的）。底层代码中，近半数都用于事件队列、回调函数队列的构建。用事件驱动来完成服务器的任务调度，这是鬼才才能想到的。针尖上的舞蹈，用一个线程，担负起了处理非常多的任务的使命。
注意这里的事件循环，也可以说是 Node.js 的一个精髓所在，下面引用一段 Node.js 官网的内容
这是Node.js事件循环的图示，描述了事件循环的不同阶段。具体来说，事件循环包括以下几个阶段：
你好，你想要展示的这张图在markdown中无法直接显示，但你可以将这张图上传至网络，然后使用以下语法在markdown中展示成图片：
┌───────────────────────────┐
┌─>│ timers │
│ └─────────────┬─────────────┘
│ ┌─────────────┴─────────────┐
│ │ pending callbacks │
│ └─────────────┬─────────────┘
│ ┌─────────────┴─────────────┐
│ │ idle, prepare │
│ └─────────────┬─────────────┘ ┌───────────────┐
│ ┌─────────────┴─────────────┐ │ incoming: │
│ │ poll │<─────┤ connections, │
│ └─────────────┬─────────────┘ │ data, etc. │
│ ┌─────────────┴─────────────┐ └───────────────┘
│ │ check │
│ └─────────────┬─────────────┘
│ ┌─────────────┴─────────────┐
└──┤ close callbacks │
└───────────────────────────┘引用Node官网中的一段内容:
注意：每个框将被称为事件循环的“阶段”。每个阶段都有一个要执行的回调FIFO队列。虽然每个阶段都以其自己的方式特殊，但通常情况下，当事件循环进入给定阶段时，它将执行特定于该阶段的任何操作，然后在该阶段的队列中执行回调，直到队列耗尽或最大回调数量为止已执行。当队列耗尽或达到回调限制时，事件循环将移至下一阶段，依此类推。关于事件循环是一个核心点，经常会被面试官考具体执行输出的问题，大家可以看我的这篇文章
跨平台
起初，Node 只能在 Linux 平台上运行。后来随着 Node的发展，微软注意到了它的存在，并投入了一个团队帮助 Node 实现 Windows 平台的兼容，在v0.6.0版本发布时，Node 已经能够直接在 Window 平台运行了。Node 是基于libuv实现跨平台的。
Node.js的弊端
单线程带来的弊端
Node.js中有一个特点就是单线程，它带来了很多好处，但是它也有弊端，单线程弱点如下。
- 无法利用多核CPU
- 错误会引起整个应用退出无法继续调用异步
I/O - 大量计算占用CPU导致无法继续调用异步
I/O
以上确实是Node的弊端，但是都会有一些对应的解决方案：
弊端1的解决方案
- 一些管理工具比如
pm2，forever等都可以实现创建多进程解决多核 CPU 的利用率问题。 - 在v0.8版本之前，实现多进程可以使用
child_process - 在v0.8版本之后，可以使用
cluster模块，通过主从模式，创建多个工作进程解决多核CPU的利用率问题。
弊端2的解决方案
- Nnigx反向代理，负载均衡，开多个进程，绑定多个端口；
- 一些管理工具比如
pm2，forever等都可以实现进程监控，错误自动重启等 - 开多个进程监听同一个端口，使用Node提供的
cluster模块； - 未出现
cluster之前，也可以使用child_process,创建多子线程监听一个端口。 这里说明下，有上面的这些解决方案，但是写node后端代码的时候，异常抛出
try catch显得格外有必要。弊端3:解决方案
- 可以把大量的密集计算像上面一样拆分成多个子线程计算
但是如果不允许拆分，想计算100万的大数据，在一个单线程中，Node确实显得无能为力，这本身就是V8内存限制的弊端。
说明：child_process与cluster模块我会单独拿一篇文章来讲。值得开心的是上面这些弊端随着Node的版本更新，和新的api模块出现，好像解决了这些弊端。
调试
用过node的人可能第一时间就会想到debug太难了，没有stack trace，因此调试比较困难。
Node社区中的npm包
Node.js社区有很多包品质良莠不齐、如果你想偷懒而又刚好npm了一个有问题的包你就很麻烦，因为代码是开源的，只能自己调试了。
Node.js的应用场景
介绍了Node.js的特点和弊端，再说一下Node.js的应用场景。
Node.js适合用来开发什么样的应用程序呢？
善于I/O，不善于计算。因为Node.js最擅长的就是任务调度，如果你的业务有很多的 CPU 计算，实际上也相当于这个计算阻塞了这个单线程，就不太适合Node开发，但是也不是没有解决方案，只是说不太适合。
当应用程序需要处理大量并发的I/O，而在向客户端发出响应之前，应用程序内部并不需要进行非常复杂的处理的时候，Node.js非常适合。Node.js也非常适合与websocket配合，开发长连接的实时交互应用程序。
具体场景可以表现为如下：
- 第一大类：用户表单收集系统、后台管理系统、实时交互系统、考试系统、联网软件、高并发量的web应用程序；
- 第二大类：基于web、canvas等多人联网游戏；
- 第三大类：基于web的多人实时聊天客户端、聊天室、图文直播；
- 第四大类：单页面浏览器应用程序；
- 第五大类：操作数据库、为前端和移动端提供基于
json的API； - 第六大类，....
哪些大公司在用
- 雅虎：雅虎开放了
Cooktail框架，将YUI3这个前端框架的能力借助Node延伸到了服务器端。 - 腾讯：将 Node 应用到长连接，以提供实时功能。
- 花瓣网，蘑菇街：通过
socket.io实现实时通知。 - 阿里：主要利用的是并行
I/O这个性能，实现高效的分布式，它们自己也出了很多Node框架 - LinkedIn：移动网站也是使用的Node
- 网易：游戏领域对并发和实时要求很高，网易开源了Node的实时框架
pomelo - 很多教育公司在用Node搭建中台或者直接作为后端
- 等等...
参考文章：本文部分内容来自朴灵老师的《深入浅出Node.js》
本文由mdnice多平台发布