Node.JS不适用的应用场景

Node.js虽然火，单并不是一门「万能」语言，也并不是所有程序员都必须学。以下应用领域和程序员不适合选择Node.js：

• 计算密集型应用。Javascript 的计算性能是很难和 C 语言代码相比的。当然，也有反例：http://onlinevillage.blogspot.jp/2011/03/is-javascript-is-faster-than-c.html，只不过不具有典型性。

• 需要精密控制内存的分配和释放的场景，如果用 Node.js 实现 Redis 数据库，虽然程序会简单不少，但是 JVM 对内存数据结构的精密控制能力是比不了用 C 语言纯手工打造的。

• 大量且需要频繁通过 C Binding 调用 C library 的情况。这种场景下，往返参数的 Marshal/Unmarshal 的成本可能会大于 C Library 带来的性能提升。

• 实时性要求很高的场景，例如：交换机或者工控机器人。这是因为所有通过垃圾回收机制来管理内存的系统都有可能在 GC 过程中产生停顿，从而影响响应速度，而且很难优化。

• 需要单一进程控制大内存的场景：v8 引擎的设计限制，在 32-bit下有 1GB 最大堆尺寸的限制，在 64-bit下是1.7GB。当然，由于 node.js buffer 的分配不是在 v8 的堆上，因此可以超过此限制。这个限制可以通过向 v8 引擎传递max_old_space_size 参数来超越，但是也会带来 GC 的性能退化。这一问题在几乎所有 GC Based 的系统下都存在。

• 不关心系统吞吐率或者不需要异步调用的场景：例如，自动化脚本，这些脚本不需要关心多用户并发访问的性能消耗。用 Python 这样的“胶水”语言写起来会更简单。

• 某些非通用场景：例如 nginx 对于静态 web server 或者 反向代理的场景是特别设计的，这些场景中 nginx 的性能比 Node.js 要好。

• 强类型强迫症：有些 Java 或者 .NET 过来的程序员会认为只有强类型语言和严格定义的类型系统是专业化的象征，构造这样的系统是架构师的使命，而动态语言只是玩具，只能用来做 Demo 或者前端开发。

• 团队成员难以理解或者接受函数式编程：Javascript 本质上更像函数式语言，有些程序员在理解和使用闭包、高阶函数等概念时总是不能习惯，这个问题在国内的开发团队中还挺普遍的。

• 回调式编程的不习惯：Node.js 的异步IO 大量依赖回调。回调让程序的执行出现了两条路径，出现故障时调用栈也很难理解。这对习惯了同步编程的程序员来说一开始确实是个坎。async, Q promise 等 package 可以缓解这个问题（在 ES6 的Generator 普及之前），不过这也带来了更陡峭的学习曲线。一般情况下，需要半年到一年的习惯过程，当然前提是多看，多写。随着越来越多的经验分享，这个过程也在不断地缩短。