自Node.js面世以来，它获得了大量的赞美和批判。这种争论会一直持续，短时间内都不会结束。而在这些争论中，我们常常会忽略掉所有语言和平台都是基于一些核心问题来批判的，就是我们怎么去使用这些平台。无论使用Node.js编写可靠的代码有多难，而编写高并发代码又是多么的简单，这个平台终究是有那么一段时间了，而且被用来创建了大量的健壮而又复杂的web服务。这些web服务不仅拥有良好的扩展性，而且通过在互联网上持续的时间证明了它们的健壮性。

然而就像其它平台一样，Node.js很容易令开发者犯错。这些错误有些会降低程序性能，有些则会导致Node.js不可用。在本文中，我们会看到Node.js新手常犯的十种错误，以及如何去避免它们。

错误#1：阻塞事件循环

Node.js（正如浏览器）里的JavaScript提供了一种单线程环境。这意味着你的程序不会有两块东西同时在运行，取而代之的是异步处理I/O密集操作所带来的并发。比如说Node.js给数据库发起一个请求去获取一些数据时，Node.js可以集中精力在程序的其他地方：

// Trying to fetch an user object from the database. Node.js is free to run other parts of the code from the moment this function is invoked..

db.User.get(userId, function(err, user) {

// .. until the moment the user object has been retrieved here

})

然而，在一个有上千个客户端连接的Node.js实例里，一小段CPU计算密集的代码会阻塞住事件循环，导致所有客户端都得等待。CPU计算密集型代码包括了尝试排序一个巨大的数组、跑一个耗时很长的函数等等。例如：

function sortUsersByAge(users) {

users.sort(function(a, b) {

return a.age < b.age ? -1 : 1

})

}

在一个小的“users”数组上调用“sortUsersByAge”方法是没有任何问题的，但如果是在一个大数组上，它会对整体性能造成巨大的影响。如果这种事情不得不做，而且你能确保事件循环上没有其他事件在等待（比如这只是一个Node.js命令行工具，而且它不在乎所有事情都是同步工作的）的话，那这没有问题。但是，在一个Node.js服务器试图给上千用户同时提供服务的情况下，它就会引发问题。

如果这个users数组是从数据库获取的，那么理想的解决方案是从数据库里拿出已排好序的数据。如果事件循环被一个计算金融交易数据历史总和的循环所阻塞，这个计算循环应该被推到事件循环外的队列中执行以免占用事件循环。

正如你所见，解决这类错误没有银弹，只有针对每种情况单独解决。基本理念是不要在处理客户端并发连接的Node.js实例上做CPU计算密集型工作。

错误#2：多次调用一个回调函数

一直以来JavaScript都依赖于回调函数。在浏览器里，事件都是通过传递事件对象的引用给一个回调函数（通常都是匿名函数）来处理。在Node.js里，回调函数曾经是与其他代码异步通信的唯一方式，直到promise出现。回调函数现在仍在使用，而且很多开发者依然围绕着它来设置他们的API。一个跟使用回调函数相关的常见错误是多次调用它们。通常，一个封装了一些异步处理的方法，它的最后一个参数会被设计为传递一个函数，这个函数会在异步处理完后被调用：

module.exports.verifyPassword = function(user, password, done) {

if(typeof password !== ‘string’) {

done(new Error(‘password should be a string’))

return

}

computeHash(password, user.passwordHashOpts, function(err, hash) {

if(err) {

done(err)

return

}

done(null, hash === user.passwordHash)

})

}

注意到除了最后一次，每次“done”方法被调用之后都会有一个return语句。这是因为调用回调函数不会自动结束当前方法的执行。如果我们注释掉第一个return语句，然后传一个非字符串类型的password给这个函数，我们依然会以调用computeHash方法结束。根据computeHash在这种情况下的处理方式，“done”函数会被调用多次。当传过去的回调函数被多次调用时，任何人都会被弄得措手不及。

避免这个问题只需要小心点即可。一些Node.js开发者因此养成了一个习惯，在所有调用回调函数的语句前加一个return关键词：

if(err) {

return done(err)

}

在很多异步函数里，这种return的返回值都是没有意义的，所以这种举动只是为了简单地避免这个错误而已。

错误#3：深层嵌套的回调函数

深层嵌套的回调函数通常被誉为“回调地狱”，它本身并不是什么问题，但是它会导致代码很快变得失控：

function handleLogin(..., done) {

db.User.get(..., function(..., user) {

if(!user) {

return done(null, ‘failed to log in’)

}

utils.verifyPassword(..., function(..., okay) {

if(okay) {

return done(null, ‘failed to log in’)

}

session.login(..., function() {

done(null, ‘logged in’)

})

})

})

}

越复杂的任务，这个的坏处就越大。像这样嵌套回调函数，我们的程序很容易出错，而且代码难以阅读和维护。一个权宜之计是把这些任务声明为一个个的小函数，然后再将它们联系起来。不过，（有可能是）最简便的解决方法之一是使用一个Node.js公共组件来处理这种异步js，比如Async.js：

function handleLogin(done) {

async.waterfall([

function(done) {

db.User.get(..., done)

},

function(user, done) {

if(!user) {

return done(null, ‘failed to log in’)

}

utils.verifyPassword(..., function(..., okay) {

done(null, user, okay)

})

},

function(user, okay, done) {

if(okay) {

return done(null, ‘failed to log in’)

}

session.login(..., function() {

done(null, ‘logged in’)

})

}

], function() {

// ...

})

}

Async.js还提供了很多类似“async.waterfall”的方法去处理不同的异步场景。为了简便起见，这里我们演示了一个简单的示例，实际情况往往复杂得多。

（打个广告，隔壁的《ES6 Generator介绍》提及的Generator也是可以解决回调地狱的哦，而且结合Promise使用更加自然，请期待隔壁楼主的下篇文章吧:D）

错误#4：期待回调函数同步执行

使用回调函数的异步程序不只是JavaScript和Node.js有，只是它们让这种异步程序变得流行起来。在其他编程语言里，我们习惯了两个语句一个接一个执行，除非两个语句之间有特殊的跳转指令。即使那样，这些还受限于条件语句、循环语句以及函数调用。

然而在JavaScript里，一个带有回调函数的方法直到回调完成之前可能都无法完成任务。当前函数会一直执行到底：

function testTimeout() {

console.log(“Begin”)

setTimeout(function() {

console.log(“Done!”)

}, duration * 1000)

console.log(“Waiting..”)

}

你可能会注意到，调用“testTimeout”函数会先输出“Begin”，然后输出“Waiting..”，紧接着几秒后输出“Done!”。

任何要在回调函数执行完后才执行的代码，都需要在回调函数里调用。

错误#5：给“exports”赋值，而不是“module.exports”

Node.js认为每个文件都是一个独立的模块。如果你的包有两个文件，假设是“a.js”和“b.js”，然后“b.js”要使用“a.js”的功能，“a.js”必须要通过给exports对象增加属性来暴露这些功能：

// a.js

exports.verifyPassword = function(user, password, done) { ... }

完成这步后，所有需要“a.js”的都会获得一个带有“verifyPassword”函数属性的对象：

// b.js

require(‘a.js’) // { verifyPassword: function(user, password, done) { ... } }

然而，如果我们想直接暴露这个函数，而不是让它作为某些对象的属性呢？我们可以覆写exports来达到目的，但是我们绝对不能把它当做一个全局变量：

// a.js

module.exports = function(user, password, done) { ... }

注意到我们是把“exports”当做module对象的一个属性。“module.exports”和“exports”这之间区别是很重要的，而且经常会使Node.js新手踩坑。

错误#6：从回调里抛出错误

JavaScript有异常的概念。在语法上，学绝大多数传统语言（如Java、C++）对异常的处理那样，JavaScript可以抛出异常以及在try-catch语句块中捕获异常：

function slugifyUsername(username) {

if(typeof username === ‘string’) {

throw new TypeError(‘expected a string username, got '+(typeof username))

}

// ...

}

try {

var usernameSlug = slugifyUsername(username)

} catch(e) {

console.log(‘Oh no!’)

}

然而，在异步环境下，tary-catch可能不会像你所想的那样。比如说，如果你想用一个大的try-catch去保护一大段含有许多异步处理的代码，它可能不会正常的工作：

try {

db.User.get(userId, function(err, user) {

if(err) {

throw err

}

// ...

usernameSlug = slugifyUsername(user.username)

// ...

})

} catch(e) {

console.log(‘Oh no!’)

}

如果“db.User.get”的回调函数异步执行了，那么try-catch原来所在的作用域就很难捕获到回调函数里抛出的异常了。

这就是为什么在Node.js里通常使用不同的方式处理错误，而且这使得所有回调函数的参数都需要遵循(err, …)这种形式，其中第一个参数是错误发生时的error对象。

错误#7：认为Number是一种整型数据格式

在JavaScript里数字都是浮点型，没有整型的数据格式。你可能认为这不是什么问题，因为数字大到溢出浮点型限制的情况很少出现。可实际上，当这种情况发生时就会出错。因为浮点数在表达一个整型数时只能表示到一个最大上限值，在计算中超过这个最大值时就会出问题。也许看起来有些奇怪，但在Node.js中下面代码的值是true：

Math.pow(2, 53)+1 === Math.pow(2, 53)

很不幸的是，JavaScript里有关数字的怪癖可还不止这些。尽管数字是浮点型的，但如下这种整数运算能正常工作：

5 % 2 === 1 // true

5 >> 1 === 2 // true

然而和算术运算不同的是，位运算和移位运算只在小于32位最大值的数字上正常工作。例如，让“Math.pow(2, 53)”位移1位总是得到0，让其与1做位运算也总是得到0：

Math.pow(2, 53) / 2 === Math.pow(2, 52) // true

Math.pow(2, 53) >> 1 === 0 // true

Math.pow(2, 53) | 1 === 0 // true

你可能极少会去处理如此大的数字，但如果你需要的话，有很多实现了大型精密数字运算的大整数库可以帮到你，比如node-bigint。

错误#8：忽略了流式API的优势

现在我们想创建一个简单的类代理web服务器，它能通过拉取其他web服务器的内容来响应和发起请求。作为例子，我们创建一个小型web服务器为Gravatar的图像服务。

var http = require('http')

var crypto = require('crypto')

http.createServer()

.on('request', function(req, res) {

var email = req.url.substr(req.url.lastIndexOf('/')+1)

if(!email) {

res.writeHead(404)

return res.end()

}

var buf = new Buffer(1024*1024)

http.get('http://www.gravatar.com/avatar/'+crypto.createHash('md5').update(email).digest('hex'), function(resp) {

var size = 0

resp.on('data', function(chunk) {

chunk.copy(buf, size)

size += chunk.length

})

.on('end', function() {

res.write(buf.slice(0, size))

res.end()

})

})

})

.listen(8080)

在这个例子里，我们从Gravatar拉取图片，将它存进一个Buffer里，然后响应请求。如果Gravatar的图片都不是很大的话，这样做没问题。但想象下如果我们代理的内容大小有上千兆的话，更好的处理方式是下面这样：

http.createServer()

.on('request', function(req, res) {

var email = req.url.substr(req.url.lastIndexOf('/')+1)

if(!email) {

res.writeHead(404)

return res.end()

}

http.get('http://www.gravatar.com/avatar/'+crypto.createHash('md5').update(email).digest('hex'), function(resp) {

resp.pipe(res)

})

})

.listen(8080)

这里我们只是拉取图片然后简单地以管道方式响应给客户端，而不需要在响应它之前读取完整的数据存入缓存。

错误#9：出于Debug的目的使用Console.log

在Node.js里，“console.log”允许你打印任何东西到控制台上。比如传一个对象给它，它会以JavaScript对象的字符形式打印出来。它能接收任意多个的参数并将它们以空格作为分隔符打印出来。有很多的理由可以解释为什么开发者喜欢使用它来debug他的代码，然而我强烈建议你不要在实时代码里使用“console.log”。你应该要避免在所有代码里使用“console.log”去debug，而且应该在不需要它们的时候把它们注释掉。你可以使用一种专门做这种事的库代替，比如debug。

这些库提供了便利的方式让你在启动程序的时候开启或关闭具体的debug模式，例如，使用debug的话，你能够阻止任何debug方法输出信息到终端上，只要不设置DEBUG环境变量即可。使用它十分简单：

// app.js

var debug = require(‘debug’)(‘app’)

debug(’Hello, %s!’, ‘world’)

开启debug模式只需简单地运行下面的代码把环境变量DEBUG设置到“app”或“*”上：

DEBUG=app node app.js

错误#10：不使用监控程序

不管你的Node.js代码是跑在生产环境或是你的本地开发环境，一个能协调你程序的监控程序是十分值得拥有的。一条经常被开发者提及的，针对现代程序设计和开发的建议是你的代码应该有fail-fast机制。如果发生了一个意料之外的错误，不要尝试去处理它，而应该让你的程序崩溃然后让监控程序在几秒之内重启它。监控程序的好处不只是重启崩溃的程序，这些工具还能让你在程序文件发生改变的时候重启它，就像崩溃重启那样。这让开发Node.js程序变成了一个更加轻松愉快的体验。

Node.js有太多的监控程序可以使用了，例如：

pm2

forever

nodemon

supervisor

所有这些工具都有它的优缺点。一些擅长于在一台机器上处理多个应用程序，而另一些擅长于日志管理。不管怎样，如果你想开始写一个程序，这些都是不错的选择。

总结

你可以看到，这其中的一些错误能给你的程序造成破坏性的影响，在你尝试使用Node.js实现一些很简单的功能时一些错误也可能会导致你受挫。即使Node.js已经使得新手上手十分简单，但它依然有些地方容易让人混乱。从其他语言过来的开发者可能已知道了这其中某些错误，但在Node.js新手里这些错误都是很常见的。幸运的是，它们都可以很容易地避免。我希望这个简短指南能帮助新手更好地编写Node.js代码，而且能够给我们大家开发出健壮高效的软件。

更多信息请查看IT技术专栏