如何决定何时使用Node.js？
我对这种东西是陌生的，但是最近我已经听到很多关于Node.js有多出色的信息。 考虑到我一般喜欢使用jQuery和JavaScript有多少，我不禁想知道如何决定何时使用Node.js。 我想到的Web应用程序有点像Bitly-需要一些内容，然后将其存档。
从过去几天我所做的所有作业中，我获得了以下信息。 Node.js
- 是一种命令行工具，可以作为常规Web服务器运行，并且可以运行一个JavaScript程序
- 利用强大的V8 JavaScript引擎
- 需要同时做几件事时非常好
- 是基于事件的，因此所有出色的类似于Ajax的工作都可以在服务器端完成
- 让我们在浏览器和后端之间共享代码
- 让我们与MySQL对话
我遇到的一些来源是：
考虑到Node.js几乎可以直接在亚马逊的EC2实例上运行，我试图了解Node.js需要哪种类型的问题，而不是像PHP ， Python和Ruby这样的强大之王。 我知道这确实取决于一个人在某种语言上的专业知识，但是我的问题更多地归结为以下一般类别：什么时候使用特定框架，它特别适合什么类型的问题？
#1楼
没有什么比银子弹更像了。 一切都伴随着一些成本。 就像您吃油腻的食物一样，您会损害自己的健康，健康的食物不会像油腻的食物那样带有香料。 他们是想要健康还是在食物中添加香料是个人选择。 Node.js被认为用于特定场景的方式相同。 如果您的应用程序不适合这种情况，则不应在应用程序开发中考虑它。 我只是将我的想法放在相同的地方：
何时使用Node.JS
- 如果您的服务器端代码需要很少的cpu周期。 在其他情况下，您正在执行非阻塞操作，并且没有繁重的算法/作业，因此不占用大量CPU周期。
- 如果您来自Javascript领域，并且喜欢像客户端JS一样编写单线程代码。
何时不使用Node.JS
- 您的服务器请求取决于占用大量CPU的算法/作业。
Node.JS的可伸缩性注意事项
- Node.JS本身并未利用底层系统的所有核心，并且默认情况下它是单线程的，因此您必须自己编写逻辑以利用多核处理器并使之成为多线程。
Node.JS替代品
还有其他选项可以代替Node.JS，但是Vert.x似乎很有前途，并具有诸如polygot和更好的可伸缩性考虑之类的许多附加功能。
#2楼
我的作品：nodejs非常适合制作实时系统，例如分析，聊天应用程序，api，广告服务器等。该死，我在2小时内使用nodejs和socket.io制作了我的第一个聊天应用程序，而考试周也是如此！
编辑
自从我开始使用nodejs以来已经有好几年了，我已经将它用于制作许多不同的东西，包括静态文件服务器，简单的分析，聊天应用程序等等。 这是我何时使用nodejs的观点
何时使用
在制作强调并发性和速度的系统时。
- 仅套接字服务器，例如聊天应用程序，irc应用程序等。
- 社交网络强调实时资源，例如地理位置，视频流，音频流等。
- 像分析网络应用程序一样，真正快速地处理小数据块。
- 公开仅REST的api。
什么时候不使用
它是一种非常通用的Web服务器，因此您可以在任何地方使用它，但可能不在这些地方。
- 简单的博客和静态站点。
- 就像静态文件服务器一样。
请记住，我只是在挑剔。 对于静态文件服务器，apache更好，主要是因为它广泛可用。 这些年来，nodejs社区变得越来越大，越来越成熟，可以肯定地说，如果您有自己的托管选择，那么nodejs几乎可以在任何地方使用。
#3楼
我有一个使用Node.js的真实示例。 我工作的公司有一位客户希望拥有一个简单的静态HTML网站。 该网站用于使用PayPal出售一件商品，客户还希望拥有一个可以显示所售商品数量的柜台。 客户预计将有大量访问该网站的访客。 我决定使用Node.js和Express.js框架进行计数。
Node.js应用程序很简单。 从Redis数据库获取已售商品数量，在售出商品时增加计数器，并通过API将计数器值提供给用户。
在这种情况下选择使用Node.js的一些原因
- 它非常轻巧且快速。 在三个星期内，该网站的访问量已超过200000，并且最少的服务器资源已能够处理所有这些。
- 计数器很容易成为实时计数器。
- Node.js易于配置。
- 有许多免费的模块。 例如，我找到了PayPal的Node.js模块。
在这种情况下，Node.js是一个了不起的选择。
#4楼
我认为没有人提到过Node.js的另一件事是令人惊叹的社区，程序包管理系统（npm）以及只需将它们包含在package.json文件中就可以包含的现有模块数量。
#5楼
我为新项目选择Node.js的另一个原因是：
能够进行基于纯云的开发
我已经使用Cloud9 IDE一段时间了，现在没有它我无法想象，它涵盖了所有开发生命周期。 您所需要的只是一个浏览器，您可以随时随地在任何设备上进行编码。 您无需在一台计算机（例如在家）中检入代码，然后在另一台计算机（例如在工作场所）中检出代码。
当然，也许有适用于其他语言或平台的基于云的IDE（Cloud 9 IDE也添加了对其他语言的支持），但是使用Cloud 9进行Node.js开发对我来说确实是很棒的体验。
#6楼
使用NodeJS的原因：
它运行Javascript，因此您可以在服务器和客户端上使用相同的语言 ，甚至在它们之间共享一些代码（例如，用于表单验证或在任一端呈现视图）。
通过NPM可以访问不断增长的软件包池，包括客户端和服务器端库/模块，以及用于Web开发的命令行工具。 其中大多数都方便地托管在github上，有时您可以在其中报告问题，并在数小时内发现问题！ 将所有内容都放在一个屋顶下非常好，它具有标准化的问题报告和易于分叉的功能。
它已成为事实上的标准环境，可以在其中运行与Javascript相关的工具以及与其他Web相关的工具 ，包括任务运行程序，缩小程序，美化程序，短毛绒，预处理程序，打包程序和分析处理器。
它似乎非常适合原型设计，敏捷开发和快速产品迭代 。
不使用NodeJS的原因：
它运行Javascript，而Javascript没有编译时类型检查。 对于大型的，复杂的，对安全至关重要的系统，或者包括不同组织之间的协作在内的项目，从长远来看，鼓励合同界面并提供静态类型检查的语言可以为您节省一些调试时间（和爆炸时间）。 （尽管JVM始终使用
null，但请在您的核反应堆中使用Haskell。）除此之外，NPM中的许多软件包都有些原始 ，并且仍在快速发展中。 一些用于较旧框架的库已经过了十年的测试和错误修复，并且目前非常稳定 。 Npmjs.org没有对包进行评分的机制 ，这导致了做相同事情的包激增，其中很大一部分不再被维护。
嵌套回调地狱。 （当然，对此有20种不同的解决方案 ...）
不断增长的软件包池可以使一个NodeJS项目与下一个完全不同 。 由于存在大量可用的选项（例如Express / Sails.js / Meteor / Derby ），因此实现的多样性很大。 有时候，这会使新开发人员更难以加入Node项目。 与Rails开发人员加入现有项目相反：他应该能够很快熟悉该应用程序，因为鼓励所有Rails应用程序使用类似的结构 。
处理文件可能会有些麻烦。 在其他语言中琐碎的事情，例如从文本文件中读取一行，对于使用Node.js来说是很奇怪的 ，因此有80个以上的表决存在StackOverflow问题。 没有简单的方法可以一次从CSV文件读取一条记录 。 等等。
我喜欢NodeJS，它快速，狂野且有趣，但是我担心它对可证明的正确性兴趣不大。 希望我们最终能够融合两全其美。 我渴望看到将来将取代Node的... :)
#7楼
节点提供的另一项功能是可以动态使用节点的子进程（每个doc要求10mb内存）创建节点的多个v8实例，因此不会影响运行服务器的主进程。 因此，卸载需要大量服务器负载的后台作业就成了小孩子的事，我们可以在需要时轻松杀死它们。
我已经使用了很多节点，并且在我们构建的大多数应用中，需要同时连接服务器，因此网络流量很大。 诸如Express.js和新的Koajs （已删除回调地狱）之类的框架使在节点上的工作变得更加容易。
#8楼
使用Node启动下一个项目的最重要原因...
- 所有最酷的家伙都加入其中...所以一定很有趣。
- 您可以在凉爽的地方闲逛，并有许多值得夸耀的Node冒险。
- 当涉及到云托管成本时，您是一分钱pin。
- 曾经在那里与Rails做到这一点
- 您讨厌IIS部署
- 您过去的IT工作变得越来越乏味，您希望自己处于崭新的起步阶段。
期待什么...
- 借助Express，您将感到安全无忧，而无需使用您不需要的所有服务器膨胀软件。
- 像火箭一样运行，并且缩放良好。
- 你梦到了。 您已安装。 节点软件包repo npmjs.org是世界上最大的开源库生态系统。
- 您的大脑将在嵌套的回调中浪费时间...
- ...直到您学会遵守诺言 。
- Sequelize和Passport是您的新API朋友。
- 调试大多数异步代码将变得非常有趣 。
- 是所有提名人掌握Typescript的时间 。
谁使用它？
- 贝宝，Netflix，沃尔玛，LinkedIn，Groupon，Uber，GoDaddy，道琼斯
- 这就是为什么他们切换到Node的原因。
#9楼
可以在哪里使用
- 高度事件驱动且受I / O约束的应用程序
- 处理与其他系统的大量连接的应用程序
- 实时应用程序（Node.js专为实时而设计，并且易于使用。）
- 杂乱地往返于其他来源的信息流的应用程序
- 高流量，可扩展的应用程序
- 无需进行大量数据分析即可与平台API和数据库进行通信的移动应用程序
- 构建联网的应用程序
- 需要经常与后端对话的应用程序
在移动方面，黄金时段公司依靠Node.js来提供移动解决方案。 找出原因？
LinkedIn是杰出的用户。 他们的整个移动堆栈都基于Node.js。 他们从在每台物理机上运行15台服务器（每个实例有15个实例）到仅4个实例–可以处理两倍的流量！
eBay推出了用于HTTP API的网络查询语言ql.io，该语言使用Node.js作为运行时堆栈。 他们能够调整常规的开发人员质量的Ubuntu工作站，以每个node.js进程处理超过120,000个活动连接，每个连接消耗大约2kB内存！
沃尔玛重新设计了其移动应用程序以使用Node.js，并将其JavaScript处理推到了服务器上。
有关更多信息，请访问： http ： //www.pixelatingbits.com/a-closer-look-at-mobile-app-develop-with-node-js/
#10楼
如果您的应用程序主要是束缚Web api或其他io通道，使用或使用用户界面，那么node.js可能是您的不二之选，特别是如果您想获得最大的可扩展性，或者如果您的生活中的主要语言是javascript（或各种javascript编译器）。 如果您构建微服务，node.js也可以。 Node.js也适用于任何规模较小或简单的项目。
它的主要卖点是，它允许前端人员对后端内容负责，而不是典型的鸿沟。 另一个合理的卖点是，如果您的工作人员一开始就以JavaScript为导向。
但是，在某个特定点之外，如果没有可怕的黑客来强迫模块性，可读性和流程控制，就无法扩展代码。 但是，有些人喜欢这些黑客，尤其是来自事件驱动的javascript背景，他们似乎很熟悉或可以原谅。
特别是，当您的应用程序需要执行同步流时，就会开始使用半熟的解决方案，这会大大降低您的开发流程速度。 如果您的应用程序中有计算密集型部分，请谨慎选择（仅）node.js。 与我最初使用node.js或编写此代码时相比，也许http://koajs.com/或其他新颖性缓解了那些最初棘手的方面。
#11楼
Node非常适合快速创建原型，但是我再也不会将它用于任何复杂的事情。 我花了20年的时间开发与编译器的关系，但我肯定会错过它。
对于维护您已经一段时间没有访问的代码，Node尤其痛苦。 类型信息和编译时错误检测是一件好事。 为什么要把所有这些都扔掉？ 为了什么？ 当当东西往南走时，堆栈痕迹常常完全没用。
#12楼
因此，让我们从一个故事开始。 从最近的两年开始，我从事JavaScript的开发和Web前端的开发，对此我感到很满意。 后端人员向我们提供了一些用Java，python（我们不在乎）编写的API，我们只需编写一个AJAX调用，获取我们的数据，然后猜测一下！ 我们完了。 但是实际上并不是那么容易，如果获取的数据不正确或服务器出现错误，那么我们就停滞了，我们必须通过邮件或聊天（有时也在whatsApp上）与我们的后端人员联系。）不酷。 如果我们用JavaScript编写API并从前端调用这些API怎么办？ 是的，这很酷，因为如果我们在API中遇到任何问题，我们可以对其进行调查。 你猜怎么了 ！ 您现在可以执行此操作吗？ –节点在那里。
好的，您可以用JavaScript编写API，但是如果我对上述问题没问题，该怎么办。 您还有其他理由将节点用于rest API吗？
这就是魔术的开始。 是的，我确实有其他理由将节点用于我们的API。
让我们回到基于阻塞操作或线程的传统rest API系统。 假设发生两个并发请求（r1和r2），每个请求都需要数据库操作。 因此，在传统系统中会发生什么：
1.等待方式：我们的服务器开始处理r1请求并等待查询响应。 r1完成后，服务器开始为r2提供服务，并且以相同的方式进行。 所以等待不是一个好主意，因为我们没有那么多时间。
2.线程方式：我们的服务器将为请求r1和r2创建两个线程，并在查询数据库后达到其目的，因此冷却速度非常快。但是这很消耗内存，因为您可以看到我们启动了两个线程，并且两个请求都在查询时问题也增加了相同的数据则必须处理类似死锁的问题。 因此，它比等待方式更好，但仍然存在问题。
现在是，节点将如何执行：
3. Nodeway：当相同的并发请求进入节点时，它将在其回调中注册一个事件，并向前移动，它将不等待特定请求的查询响应。因此，当r1请求到达时，节点的事件循环（是的，有一个事件为此目的而在节点中循环。）使用其回调函数注册事件，然后继续处理r2请求，并类似地通过其回调注册事件。 每当任何查询完成时，它都会触发其相应的事件并执行其回调以完成操作而不会被中断。
因此，没有等待，没有线程，没有内存消耗–是的，这是服务其余API的节点。
#13楼
唐宁石棉画法...
昨天我的头衔是Packt Publications，《 使用JavaScript进行反应式编程》 。 它实际上不是以Node.js为中心的标题； 前几章旨在介绍理论，而后几章则涵盖实践。 因为我真的不认为这将是适当的失败给读者一个Web服务器，Node.js的似乎远远的不二之选。 案件在打开之前就已经关闭了。
对于Node.js的使用经验，我本可以给出非常乐观的看法。 相反，我对遇到的好点和坏点很诚实。
让我在这里提供一些相关的报价：
警告：Node.js及其生态系统很热，足以严重烧伤您！
当我担任数学助教时，有人告诉我一个不明显的建议，那就是不要告诉学生某事“容易”。回想起来，原因有些明显：如果你告诉别人某事很容易，那没有看到一个解决方案最终可能会感觉到（甚至更多）愚蠢，因为他们不仅不知道如何解决问题，而且他们愚蠢到无法理解的问题很容易解决！
有些陷阱不仅惹恼了来自Python / Django的人们，如果您进行了任何更改，它们会立即重新加载源代码。 使用Node.js，默认行为是，如果您进行了更改，则旧版本将一直处于活动状态，直到时间结束或您手动停止并重新启动服务器为止。 这种不适当的行为不仅惹恼了Pythonistas； 它还会激怒提供各种解决方法的本机Node.js用户。 在撰写本文时，StackOverflow问题“在Node.js中自动重新加载文件”已超过200次投票和19个答案； 编辑将用户定向到保姆脚本node-supervisor，其主页位于http://tinyurl.com/reactjs-node-supervisor 。 这个问题使新用户有很大的机会感到愚蠢，因为他们认为自己已经解决了问题，但是旧的越野车行为是完全不变的。 而且很容易忘记弹起服务器。 我已经做过多次了。 我要传达的信息是：“不，您并不傻，因为Node.js的这种行为使您不寒而栗； 只是Node.js的设计人员没有理由在此处提供适当的行为。 请尝试解决它，也许会从节点主管或其他解决方案中获得一些帮助，但是请不要觉得自己很愚蠢。 你不是那个有问题的人。 问题出在Node.js的默认行为上。”
经过一番辩论后，本节被遗漏了，正是因为我不想给人以“这很容易”的印象。在使事情顺利进行的过程中，我反复地割手，也不想解决困难和困难。让您相信使Node.js及其生态系统正常运行是一件容易的事情，如果这对您也不是一件容易的事，那么您将不知道自己在做什么。 如果您没有在使用Node.js时遇到麻烦，那就太好了。 如果这样做，我希望您不要觉得“我很愚蠢-我一定有什么问题”。如果遇到与Node.js交互时令人讨厌的惊喜，您就不会愚蠢。 不是你！ 这是Node.js及其生态系统！
在上一章和结论不断上升之后，我并不想真正看到的附录，它讲述了我在生态系统中能够找到的东西，并为moronic文字主义提供了一种解决方法：
HTML5键值存储的服务器端实现是另一个看起来很合适但仍可以兑换的数据库。 这种方法具有API的主要优势，大多数优秀的前端开发人员都非常了解。 因此，它也是大多数不太出色的前端开发人员都足够了解的API。 但是，使用node-localstorage包时，虽然不提供字典语法访问（您想使用localStorage.setItem（key，value）或localStorage.getItem（key），而不是localStorage [key]），但实现了完整的localStorage语义，包括默认的5MB配额- 为什么？ 服务器端JavaScript开发人员是否需要免受自身保护？
对于客户端数据库功能，每个网站5MB的配额确实是一个宽敞且有用的喘息空间，可让开发人员使用它。 您可以设置一个低得多的配额，并且仍然可以为开发人员在cookie管理方面的改进提供不可估量的改进。 5MB的限制并不能很快地将其用于大数据客户端处理，但是有足够的余地，足智多谋的开发人员可以用来做很多事情。 但是，另一方面，5MB并不是最近任何时候购买的大多数磁盘的特别大的部分，这意味着，如果您和某个网站对合理使用磁盘空间的观点存在分歧，或者某个站点只是呆板，那么它实际上并不会花费除非您的硬盘已经太满，否则您将没有任何危险。 如果余额少一点或多一点，也许我们会更好，但是总的来说，这是解决客户端环境内在压力的一个不错的解决方案。
但是，可能会轻轻指出，当您是服务器的编写代码时，不需要任何额外的保护就可以使数据库的大小超出可容忍的5MB。 大多数开发人员既不需要也不需要充当保姆的工具，也可以防止工具存储超过5MB的服务器端数据。 而5MB的配额是客户端的黄金平衡行为，在Node.js服务器上显得有些愚蠢。 （而且，对于本附录中所述的用于多个用户的数据库，可能会有些痛苦地指出，除非每个用户帐户在磁盘上创建一个单独的数据库，否则每个用户帐户不是5MB；在每个用户帐户之间共享5MB所有用户帐户在一起。如果病毒式传播，可能会很痛苦 ！）文档指出配额是可自定义的，但是一周前发给开发人员的电子邮件询问如何更改配额，但StackOverflow问题也是如此。 。 我唯一能找到的答案是在Github CoffeeScript源代码中，该源代码作为构造函数的可选第二个整数参数列出。 这样就很容易了，您可以指定一个等于磁盘或分区大小的配额。 但是，除了移植没有意义的功能外，该工具的作者完全没有遵循非常标准的惯例，即将0解释为变量或函数的“无限”含义，其中整数将为某些资源使用指定最大限制。 最好的办法是将配额指定为Infinity：
if (typeof localStorage === 'undefined' || localStorage === null)
{
var LocalStorage = require('node-localstorage').LocalStorage;
localStorage = new LocalStorage(__dirname + '/localStorage',
Infinity);
}
按顺序交换两个评论：
人们不必要地不停地使用JavaScript来作为整体，而JavaScript成为受人尊敬的语言的一部分实际上是道格拉斯·克罗克福德（Douglas Crockford）说的： 这是好零件。 别忘了还有其他东西。”也许炙手可热的Node.js生态系统将发展自己的 “ Douglas Crockford”，他会说：“ Node.js生态系统是编码狂野西部的代码，但仍有一些真正的瑰宝可找到。 这是一个路线图。 这是几乎不需付出任何代价即可避免的领域。 这是在任何语言或环境下都能找到的最丰富的薪水的领域。”
也许其他人可以把这些话当作挑战，并跟随克罗克福德的领导，为Node.js及其生态系统写下“好的部分”和/或“更好的部分”。 我会买一份！
考虑到所有项目的热情程度和纯粹的工作时间，可能有必要在一年或两年或三年内，对撰写本文时有关未成熟生态系统的任何言论进行大幅度的调整。 在五年内说“ 2015年Node.js生态系统有几个雷区”确实很有意义。 2020年的Node.js生态系统具有多个天堂。”
#14楼
我可以分享在哪里以及为什么要使用节点js的几点。
- 对于更好的实时应用程序，如聊天，协作编辑，我们选择使用nodejs，因为它是事件基础，可将事件和数据从服务器发送到客户端。
- 简单易懂，因为它是大多数人都有想法的javascript库。
- 当前的大多数Web应用程序都趋向于有角度的js＆backbone，有了node，就很容易与客户端代码进行交互，因为两者都将使用json数据。
- 有很多可用的插件。
缺点：-
- Node将支持大多数数据库，但最好的是mongodb，它将不支持复杂的联接和其他联接。
- 编译错误...如果任何符合错误的应用程序将停止工作，那么开发人员应该以其他方式处理所有异常，我们需要再次手动启动或使用任何自动化工具来启动它。
结论：-Nodejs最好用于简单和实时的应用程序。如果您有很大的业务逻辑和复杂的功能，最好不要使用nodejs。 如果您希望与聊天和任何协作功能一起构建应用程序，则可以在特定部分使用节点，而其余部分应与您的便捷技术一起使用。
#15楼
在总结Node.js的出色功能方面，您做了出色的工作。 我的感觉是，Node.js特别适用于您想要维持从浏览器到服务器的持久连接的应用程序。 使用一种称为“长轮询”的技术 ，您可以编写一个向用户实时发送更新的应用程序。 在Ruby on Rails或Django之类的许多Web巨人上进行长时间的轮询会在服务器上产生巨大的负载，因为每个活动的客户端都要吃掉一个服务器进程。 这种情况相当于一次沥青袭击。 使用Node.js之类的服务器时，服务器无需为每个打开的连接维护单独的线程。
这意味着您可以在Node.js中创建一个基于浏览器的聊天应用程序 ，该应用程序几乎不需要占用系统资源即可为大量客户端提供服务。 每当您想进行这种长轮询时，Node.js都是一个不错的选择。
值得一提的是，Ruby和Python都具有执行此类操作的工具（分别是eventmachine和twisted ），但是Node.js从头开始就表现出色。 JavaScript在基于回调的并发模型中处于特殊位置，并且在这里很有用。 而且，能够使用客户端和服务器都原生的JSON进行序列化和反序列化非常漂亮。
我期待在这里阅读其他答案，这是一个很棒的问题。
值得指出的是，Node.js对于在客户端/服务器之间重复使用大量代码的情况也非常有用。 Meteor框架使这变得非常容易，并且很多人都认为这可能是Web开发的未来。 我可以从经验中说，用Meteor编写代码非常有趣，其中很大一部分是花更少的时间思考如何重组数据，因此可以轻松地在浏览器中运行代码操纵它，并将其传递回去。
这是一篇有关金字塔和长轮询的文章，事实证明，在gevent的一点帮助下，设置起来非常容易： TicTacToe和金字塔长轮询 。
#16楼
我认为Node.js最适合实时应用程序：在线游戏，协作工具，聊天室或任何一个用户（或机器人？或传感器？）对应用程序有什么要求的其他用户必须立即看到的任何东西，没有页面刷新。
我还应该提到，与长期轮询相比，将Socket.IO与Node.js结合使用将减少您的实时延迟。 在最坏的情况下，Socket.IO将退回到长时间轮询，如果可用，请改用Web套接字，甚至使用Flash。
但我也应该提到，使用Node.js可以更好地解决代码可能因线程而阻塞的任何情况。 或任何需要应用程序由事件驱动的情况。
另外，Ryan Dahl在一次演讲中说，我曾经参加过，对于常规的旧HTTP请求，Node.js基准测试与Nginx紧密竞争。 因此，如果我们使用Node.js进行构建，则可以非常有效地服务于我们的常规资源，并且当我们需要事件驱动的东西时，就可以对其进行处理。
再加上所有时间都是JavaScript。 Lingua Franca整个筹码量。
#17楼
简而言之：
Node.js非常适合于具有大量并发连接的应用程序，并且每个请求仅需要很少的CPU周期，因为事件循环（与所有其他客户端一起）在函数执行期间被阻塞。
Mixu的技术博客很好地介绍了Node.js中的事件循环：了解node.js事件循环 。