你总结了Node.js的优点，做得很好。我的感觉是，Node.js特别适合那些希望保持浏览器与服务器之间持久连接的应用程序。使用称为“长轮询”的技术，您可以编写一个实时向用户发送更新的应用程序。在Ruby on Rails或Django等网络巨头上进行长时间的轮询会给服务器带来巨大的负载，因为每个活动客户端都会消耗一个服务器进程。这种情况相当于停机坪袭击。当您使用Node.js之类的东西时，服务器不需要为每个打开的连接维护单独的线程。

这意味着您可以在Node.js中创建一个基于浏览器的聊天应用程序，它几乎不需要系统资源就可以为大量客户机提供服务。任何时候你想做这种长轮询，Node.js都是一个很好的选择。

值得一提的是，Ruby和Python都有做这类事情的工具（分别是eventmachine和twisted），但Node.js从一开始就做得非常好。JavaScript非常适合基于回调的并发模型，并且在这里表现出色。此外，能够使用客户端和服务器上的JSON进行序列化和反序列化是非常不错的。

我期待着在这里阅读其他答案，这是一个很棒的问题。

值得指出的是，Node.js也非常适合在客户机/服务器之间重用大量代码的情况。Meteor框架使这变得非常简单，许多人都认为这可能是web开发的未来。根据经验，我可以说在Meteor中编写代码非常有趣，其中很大一部分是花更少的时间思考如何重组数据，这样浏览器中运行的代码就可以轻松地处理数据并将其传递回去。

这是一篇关于金字塔和长轮询的文章，事实证明，在gevent:TicTacToe和长轮询与金字塔的帮助下，这很容易设置。

我认为Node.js最适合实时应用程序：在线游戏、协作工具、聊天室，或者任何一个用户（或机器人？或传感器？）使用应用程序所做的事情都需要立即被其他用户看到，而无需刷新页面。

我还应该提到，Socket.IO与Node.js的结合将比长轮询更进一步地减少实时延迟。作为最坏的情况，Socket.IO将退回到长轮询，而是使用web套接字甚至Flash（如果可用的话）。

但我还应该提到，Node.js可以更好地解决代码可能由于线程而阻塞的任何情况，或者需要应用程序是事件驱动的任何情况。

此外，Ryan Dahl在我曾经参加的一次演讲中表示，Node.js基准测试在常规旧HTTP请求方面与Nginx不相上下。因此，如果我们使用Node.js构建，我们可以非常有效地服务于我们的正常资源，当我们需要事件驱动的东西时，它就可以处理它了。

此外，它一直都是JavaScript。整个堆栈上都是Lingua Franca。

简而言之：

Node.js非常适合具有大量并发连接的应用程序，每个请求只需要很少的CPU周期，因为事件循环（与所有其他客户端）在函数执行期间被阻塞。

关于Node.js中事件循环的一篇好文章是Mixu的技术博客：了解Node.js事件循环。

没有什么比银弹更棒的了。每件事都伴随着一些相关的成本。就好像你吃了油腻的食物，你会损害你的健康，而健康的食物不会像油腻的食物一样含有香料。无论他们想要健康还是食物中的香料，都是个人的选择。Node.js考虑在特定场景中使用的方式相同。如果你的应用程序不适合这种情况，你就不应该在你的应用开发中考虑它。我只是把我的想法放在同一点上：

何时使用Node.JS

如果服务器端代码需要很少的cpu周期。在另一个世界中，您正在执行非阻塞操作，并且没有消耗大量CPU周期的繁重算法/作业。如果您来自Javascript后台，并且能够像客户端JS一样轻松编写单线程代码。

何时不使用Node.JS

您的服务器请求取决于消耗大量CPU的算法/作业。

Node.JS的可扩展性考虑

Node.JS本身并没有利用底层系统的所有核心，默认情况下它是单线程的，您必须自己编写逻辑以利用多核心处理器并使其成为多线程的。

Node.JS替代方案

还有其他选项可以代替Node.JS，但Vert.x似乎很有前途，并且有很多其他功能，如多边形和更好的可扩展性考虑。

我的作品：nodejs非常适合制作实时系统，如分析、聊天应用程序、api、广告服务器等。见鬼，我用nodejs和socket.io制作了我的第一个聊天应用程序，时间不到2小时，考试期间也是如此周

Edit

我开始使用nodejs已经好几年了，我用它制作了很多不同的东西，包括静态文件服务器、简单分析、聊天应用等等。这是我对何时使用nodejs的看法

何时使用

在制作强调并发性和速度的系统时。

仅套接字服务器，如聊天应用程序、irc应用程序等。社交网络强调实时资源，如地理位置、视频流、音频流等。处理小数据块的速度非常快，就像一个分析Web应用程序。作为公开仅REST api。

何时不使用

它是一个非常多功能的Web服务器，因此您可以在任何地方使用它，但可能不是这些地方。

简单的博客和静态网站。就像静态文件服务器一样。

记住，我只是吹毛求疵。对于静态文件服务器，apache更好，主要是因为它广泛可用。多年来，nodejs社区已经变得越来越大，越来越成熟，如果您有自己的托管选择，可以放心地说nodejs几乎可以在任何地方使用。

我有一个真实世界的例子，我使用过Node.js。我所在的公司有一个客户想要一个简单的静态HTML网站。该网站用于使用PayPal销售一件物品，客户还希望有一个显示售出物品数量的柜台。客户预计会有大量访客访问本网站。我决定使用Node.js和Express.js框架制作计数器。

Node.js应用程序很简单。从Redis数据库中获取已售出物品的数量，在物品售出时增加计数器，并通过API向用户提供计数器值。

在本例中我选择使用Node.js的一些原因

它非常轻便和快速。在三个星期内，这个网站的访问量超过了200000次，服务器资源已经能够处理这一切。计数器很容易做到实时。Node.js易于配置。有很多模块可以免费使用。例如，我找到了PayPal的Node.js模块。

在本例中，Node.js是一个很棒的选择。

我认为没有人提到Node.js的另一个伟大之处是它的社区、包管理系统（npm）以及存在的模块数量，只需将它们包含在package.json文件中即可。

我为新项目选择Node.js的另一个原因是：

能够进行纯云开发

我使用Cloud9IDE已经有一段时间了，现在我无法想象没有它，它涵盖了所有的开发生命周期。你只需要一个浏览器，你可以随时随地在任何设备上进行编码。您不需要在一台计算机（如在家中）中签入代码，然后在另一台计算机中签出（如在工作场所）。

当然，可能有其他语言或平台的基于云的IDE（cloud 9 IDE也增加了对其他语言的支持），但使用cloud 9进行Node.js开发对我来说真的是一种很棒的体验。

使用NodeJS的原因：

它运行Javascript，因此您可以在服务器和客户端上使用相同的语言，甚至可以在它们之间共享一些代码（例如，用于表单验证或在任意一端呈现视图）与传统的多线程Java或ROR框架相比，单线程事件驱动系统即使在一次处理大量请求时也很快，而且很简单。通过NPM可访问的软件包数量不断增加，包括客户端和服务器端库/模块，以及用于web开发的命令行工具。其中大多数都方便地托管在github上，有时您可以在那里报告问题并在数小时内找到解决方案！一切都在一个屋檐下，有标准化的问题报告和轻松的分叉，这很好。它已经成为运行Javascript相关工具和其他web相关工具的实际标准环境，包括任务运行器、缩小器、美化器、linter、预处理器、打包器和分析处理器。它似乎非常适合于原型设计、敏捷开发和快速产品迭代。

不使用NodeJS的原因：

它运行Javascript，没有编译时类型检查。对于大型、复杂的安全关键系统或项目，包括不同组织之间的协作，一种鼓励契约接口并提供静态类型检查的语言可能会从长远来看为您节省一些调试时间（和爆炸）。（虽然JVM被设置为null，但请为您的核反应堆使用Haskell。）除此之外，NPM中的许多软件包都有点生涩，而且仍在快速开发中。一些旧框架的库已经经历了十年的测试和错误修复，现在非常稳定。Npmjs.org没有对软件包进行评级的机制，这导致了软件包的激增，这些软件包或多或少都在做同样的事情，其中很大一部分不再被维护。嵌套回调地狱。（当然，有20种不同的解决方案……）不断增长的包池可能会使一个NodeJS项目与下一个项目截然不同。由于有大量的可用选项（例如Express/Sails.js/Metator/Deby），实现方式存在很大的差异。这有时会使新开发人员更难加入Node项目。与加入现有项目的Rails开发人员相比，他应该能够很快熟悉应用程序，因为所有Rails应用程序都被鼓励使用类似的结构。处理文件可能有点麻烦。在其他语言中很琐碎的事情，比如从文本文件中读取一行，对于Node.js来说是非常奇怪的，因此有一个StackOverflow问题，有80多个赞成票。从CSV文件中一次读取一条记录没有简单的方法。等

我喜欢NodeJS，它很快，很狂野，很有趣，但我担心它对可证明的正确性没什么兴趣。让我们希望我们最终能够将这两个世界中最好的结合起来。我很想知道未来会有什么替代Node…：）

node提供的另一项功能是能够使用node的子进程（childProcess.f分叉（），每个进程需要10mb内存，根据文档）动态创建多个v8实例，从而不会影响运行服务器的主进程。因此，卸载需要巨大服务器负载的后台工作就成了一个孩子的游戏，我们可以在需要时轻松地杀死他们。

我一直在使用节点，在我们构建的大多数应用程序中，同时需要服务器连接，因此网络流量很大。Express.js和新的Koajs（去掉了回调地狱）等框架使节点的工作变得更加容易。

使用Node开始下一个项目的最重要原因。。。

所有最酷的男人都喜欢它。。。所以一定很有趣。你可以在冰箱里闲逛，并有很多Node冒险可以吹嘘。在云托管成本方面，你是个吝啬鬼。用Rails做过您讨厌IIS部署你以前的IT工作变得相当枯燥，你希望你在一个闪亮的新创业公司。

期待什么。。。

使用Express时，您将感到安全无忧，无需任何服务器膨胀软件。像火箭一样跑，而且伸缩性很好。你梦想着它，你安装了它。节点包repo npmjs.org是世界上最大的开源库生态系统。你的大脑会在嵌套回调的土地上扭曲时间。。。…直到你学会遵守诺言。Sequelize和Passport是您的API新朋友。调试大部分异步代码将得到。。。有趣的所有Noder掌握Typescript的时间。

谁使用它？

PayPal、Netflix、沃尔玛、LinkedIn、Groupon、优步、GoDaddy、道琼斯这就是他们切换到Node的原因。

它可以用于

高度事件驱动且严重受I/O限制的应用程序处理与其他系统的大量连接的应用程序实时应用程序（Node.js是从一开始就为实时和简单而设计的使用。）应用程序可以处理来自其他来源的大量信息流高流量、可扩展的应用程序移动应用程序必须与平台API和数据库通信，而无需处理大量数据分析构建网络应用程序需要经常与后端通信的应用程序

在移动方面，黄金时段公司的移动解决方案依赖Node.js。看看为什么？

LinkedIn是一个杰出的用户。他们的整个移动堆栈都建立在Node.js上。他们从在每台物理机器上运行15个服务器和15个实例，到只运行4个实例，可以处理双倍的流量！

eBay推出了ql.io，这是一种用于HTTP API的web查询语言，它使用Node.js作为运行时堆栈。他们能够调整一个常规开发人员质量的Ubuntu工作站，以处理每个node.js进程超过120000个活动连接，每个连接消耗大约2kB内存！

沃尔玛将其移动应用程序重新设计为使用Node.js，并将其JavaScript处理推送到服务器。

更多信息请访问：http://www.pixelatingbits.com/a-closer-look-at-mobile-app-development-with-node-js/

如果您的应用程序主要使用webapi或其他io通道，提供或接受用户界面，node.js可能是您的最佳选择，特别是如果您想最大限度地发挥可伸缩性，或者如果您的主要语言是javascript（或javascript转译器）。如果您构建微服务，node.js也可以。Node.js也适用于任何小型或简单的项目。

它的主要卖点是让前台人员负责后端工作，而不是典型的分工。另一个合理的卖点是，如果您的员工从一开始就面向javascript。

然而，超过某一点后，如果没有强制模块化、可读性和流控制的可怕技巧，就无法扩展代码。尽管有些人喜欢这些黑客，尤其是来自事件驱动的javascript背景，但他们似乎很熟悉或可以原谅。

特别是，当您的应用程序需要执行同步流时，您会开始使用半生不熟的解决方案，这会大大降低开发过程的速度。如果应用程序中有计算密集型部分，请谨慎选择（仅）node.jshttp://koajs.com/与我最初使用node.js或编写这篇文章时相比，其他新奇之处减轻了这些原本棘手的方面。

Node非常适合快速原型，但我再也不会将其用于任何复杂的事情。我花了20年时间与编译器建立了关系，我真的很怀念它。节点对于维护您已经有一段时间没有访问过的代码尤其痛苦。类型信息和编译时错误检测是好事。为什么要扔掉这些？为了什么？当有东西向南移动时，堆栈的痕迹往往完全没有用。

最适合并发请求处理的节点-

那么，让我们从一个故事开始。在过去的两年里，我一直致力于JavaScript和开发web前端，我很喜欢它。后端的家伙们为我们提供了一些用Java、python编写的API（我们不在乎），我们只需编写一个AJAX调用，获取数据，然后猜一猜！我们完成了。但实际上，这并不是那么容易，如果我们获取的数据不正确或存在服务器错误，那么我们就卡住了，我们必须通过邮件或聊天联系我们的后端人员（有时也在whatsApp上：）这不酷。如果我们用JavaScript编写API并从前端调用这些API呢？是的，这很酷，因为如果我们在API中遇到任何问题，我们可以调查它。猜猜看！你现在可以这样做了，怎么做节点就在那里。

Ok同意您可以用JavaScript编写API，但如果我对上述问题没有异议，该怎么办。您还有其他理由使用node for rest API吗？

这就是魔法的开始。是的，我确实有其他理由将节点用于我们的API。

让我们回到传统的rest API系统，它基于阻塞操作或线程。假设发生两个并发请求（r1和r2），每个请求都需要数据库操作。因此，在传统系统中会发生什么：

1.等待方式：我们的服务器开始服务r1请求并等待查询响应。r1完成后，服务器开始为r2服务，并以相同的方式执行。所以等待不是一个好主意，因为我们没有那么多时间。

2.线程方式：我们的服务器将为两个请求r1和r2创建两个线程，并在查询数据库后达到它们的目的，速度非常快。但这会消耗内存，因为您可以看到，我们启动了两个线程。当两个请求都在查询同一数据时，问题也会增加，因此您必须处理死锁问题。所以这比等待要好，但问题仍然存在。

现在，节点将如何执行此操作：

3.Nodeway：当同一个并发请求进入节点时，它将使用回调注册一个事件，并继续前进，它不会等待特定请求的查询响应。因此，当r1请求到来时，节点的事件循环（是的，节点中有一个事件循环用于此目的）。)使用其回调函数注册事件，并继续服务r2请求，同样，使用回调函数注册其事件。每当任何查询完成时，它都会触发相应的事件，并在不中断的情况下执行回调以完成。

所以，无需等待，无需线程，无需内存消耗——是的，这是服务rest API的节点方式。

做石棉长内裤。。。

昨天我的标题是Packt Publications，Reactive Programming with JavaScript。它实际上不是一个以Node.js为中心的标题；前几章旨在涵盖理论，后几章则涉及实践。因为我真的认为不给读者一个Web服务器是不合适的，所以Node.js似乎是最明显的选择。案件甚至在开庭前就已结案。

我本可以对我使用Node.js的经历给出一个非常乐观的看法。相反，我诚实地讲述了我遇到的好点和坏点。

让我在这里引用几句相关的话：

警告：Node.js及其生态系统很热——热到足以让你严重烧伤！当我还是一名数学助教时，有人告诉我一个不明显的建议，那就是不要告诉学生什么是“容易的”。回想起来，原因有点明显：如果你告诉人们什么是容易的，没有找到解决方案的人可能会觉得（甚至更）愚蠢，因为他们不仅不知道如何解决问题，但他们太愚蠢而无法理解的问题很简单！Python/Django中的一些陷阱不仅会惹恼来自Python/Django的人，如果你做了任何更改，它会立即重新加载源代码。对于Node.js，默认行为是，如果您进行了一次更改，旧版本将继续处于活动状态，直到时间结束或手动停止并重新启动服务器。这种不恰当的行为不仅惹恼了蟒蛇爱好者；这也激怒了提供各种变通方法的本地Node.js用户。StackOverflow问题“在Node.js中自动重新加载文件”在撰写本文时获得了超过200个赞成票和19个答案；编辑会将用户引导到保姆脚本、节点主管，主页位于http://tinyurl.com/reactjs-node-supervisor.这个问题为新用户提供了很大的机会，让他们觉得自己很愚蠢，因为他们认为自己已经解决了这个问题，但旧的错误行为完全没有改变。而且很容易忘记跳出服务器；我已经做过多次了。我想传达的信息是， “不，你并不傻，因为Node.js的这种行为让你背上了背；只是Node.js设计人员认为没有理由在这里提供适当的行为。请尝试应对它，也许可以从节点主管或其他解决方案那里获得一些帮助，但请不要觉得自己很傻。你不是有问题的人；问题是Node.js默认的行为。”经过一番辩论后，这一部分被保留了下来，正是因为我不想给人一种“这很容易”的印象。我在工作时反复剁手，我不想克服困难，让你相信让Node.js及其生态系统正常运行是一件简单的事，如果这对你来说也不简单，你不知道你在做什么。如果您在使用Node.js时没有遇到令人讨厌的困难，那就太好了。如果你这样做了，我希望你不要走开时觉得，“我很傻，一定是我出了什么问题。”如果你在处理Node.js时遇到了令人讨厌的意外，那你就不傻了。不是你！这是Node.js及其生态系统！

在最后几章和结论中，我并不真正想要附录，它讲述了我在生态系统中找到的东西，并为愚蠢的文学主义提供了一个变通方法：

另一个看起来非常适合的数据库，也可能是可赎回的，是HTML5键值存储的服务器端实现。这种方法具有API的主要优势，大多数优秀的前端开发人员都非常了解该API。就这一点而言，它也是大多数不太好的前端开发人员都足够理解的API。但是对于节点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解释为变量或函数的“无限”，其中整数将指定某些资源使用的最大限制。处理此错误功能的最佳方法可能是指定配额为无限：

if (typeof localStorage === 'undefined' || localStorage === null)
  {      
  var LocalStorage = require('node-localstorage').LocalStorage;
  localStorage = new LocalStorage(__dirname + '/localStorage',
    Infinity);
  }

按顺序交换两个注释：

人们不必要地不断使用JavaScript作为一个整体来攻击自己的脚，而JavaScript成为一种值得尊敬的语言的一部分，正如道格拉斯·克罗克福德（Douglas Crockford）所说，“JavaScript作为一种语言，有一些真正好的部分，也有一些真正坏的部分。这里有好的部分。请忘记其他任何东西。“也许炙手可热的Node.js生态系统会发展出自己的”Douglas Crockford“，他会说，”Node.js的生态系统是一个编码狂野的西部，但有一些真正的宝石可以找到。这里有一个路线图。这里有一些几乎不惜任何代价都可以避免的领域。这里有任何语言或环境中都可以找到的一些最有钱的领域。”也许其他人可以把这些话当作一个挑战，跟随克罗克福德的领导，为Node.js及其生态系统写下“好的部分”和/或“更好的部分”。我会买一本！考虑到所有项目的热情程度和纯粹的工作时间，可能需要在一年、两年或三年内对本文撰写时关于不成熟生态系统的任何言论进行严厉的批评。五年后说：“2015年Node.js生态系统有几个雷区。2020年Node.jss生态系统有多个天堂。”

我可以分享一些使用node js的地方和原因。

对于聊天、协作编辑等实时应用程序，我们最好使用nodejs，因为它是从服务器向客户端发送事件和数据的事件库。简单易懂，因为它是大多数人都知道的javascript基础。当前的大多数web应用程序都倾向于使用angular js和主干，使用节点很容易与客户端代码交互，因为两者都将使用json数据。有很多插件可用。

缺点：-

节点将支持大多数数据库，但最好的是mongodb，它不支持复杂的连接和其他。编译错误。。。开发人员应该以其他方式处理每一个异常，如果任何error accord应用程序将停止工作，我们需要再次手动或使用任何自动化工具启动它。

结论：-Nodejs最适合用于简单和实时应用程序。。如果您有非常大的业务逻辑和复杂的功能，最好不要使用nodejs。如果您想构建一个应用程序以及聊天和任何协作功能。。节点可以用在特定的部件中，并保留下来。