node 常见10个错误

node 常见10个错误

错误 #1：阻塞事件循环

JavaScript在 Node.js (就像在浏览器一样) 提供单线程执行环境。这意味着你的程序不能同时执行两部分代码，但能通过 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…

// 尝试从数据库中获取一个用户对象。在这个函数执行的一刻，Node.js 有空去运行代码其它部分…

db.User.get(userId, function(err, user) {
// … until the moment the user object has been retrieved here

// … 直到用户对象检索到这里的那一刻

})

然而，具有计算密集型代码的 Node.js 实例被数以万计客户端同时连接执行时，会导致阻塞事件循环，并使所有客户端处于等待响应状态。计算密集型代码，包括尝试给一个庞大数组进行排序操作和运行一个格外长的循环等。例如：

function sortUsersByAge(users) {
    users.sort(function(a, b) {
    return a.age > b.age ? -1 : 1
    })
}

基于小 “users” 数组执行 “sortUserByAge” 函数，可能没什么问题，当基于庞大数组时，会严重影响整体性能。如果在不得不这样操作的情况下，你必须确保程序除了等待事件循环而别无他事（例如，用 Node.js 建立命令行工具的一部分，整个东西同步运行是没问题的），然后这可能没问题。然而，在 Node.js 服务器实例尝试同时服务成千上万个用户的情况下，这将是一个毁灭性的问题。

如果用户数组是从数据库检索出来的，有个解决办法是，先在数据库中排序，然后再直接检索。如果因需要计算庞大的金融交易历史数据总和，而造成阻塞事件循环，这可以创建额外的worker / queue 来避免阻塞事件循环。

正如你所看到的，这没有新技术来解决这类 Node.js 问题，而每种情况都需要单独处理。而基本解决思路是：不要让 Node.js 实例的主线程执行 CPU 密集型工作 – 客户端同时链接时。

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

JavaScript一直都是依赖于回调函数。在浏览器中，处理事件是通过调用函数（通常是匿名的），这个动作如同回调函数。Node.js 在引进 promises 之前，回调函数是异步元素用来互相连接对方的唯一方式 。现在回调函数仍被使用，并且包开发者仍然围绕着回调函数设计 APIs。一个关于使用回调函数的常见 Node.js 问题是：不止一次调用。通常情况下，一个包提供一个函数去异步处理一些东西，设计出来是期待有一个函数作为最后一个参数，当异步任务完成时就会被调用：

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），而最后一个 “done” 则可省略返回语句。这是因为调用回调函数后，并不会自动结束当前执行函数。如果第一个 “return” 注释掉，然后给这个函数传进一个非字符串密码，导致 “computeHash” 仍然会被调用。这取决于 “computeHash” 如何处理这样一种情况，“done” 可能会调用多次。任何一个人在别处使用这个函数可能会变得措手不及，因为它们传进的该回调函数被多次调用。

只要小心就可以避免这个 Node.js 错误。而一些 Node.js 开发者养成一个习惯是：在每个回调函数调用前添加一个 return 关键字。 if(err) { return done(err) }

对于许多异步函数，它的返回值几乎是无意义的，所以该方法能让你很好地避免这个问题。

错误 #3：函数嵌套过深

函数嵌套过深，时常被称为“回调函数地狱”，但这并不是 Node.js 自身问题。然而，这会导致一个问题：代码很快失去控制。

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 工具包，它专门处理异步 JavaScript模式，例如 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.waterfall”，Async.js 提供了很多其它函数来解决不同的异步模式。为了简洁，我们在这里使用一个较为简单的案例，但实际情况往往更糟。

错误 #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 将每个文件视为一个孤立的小模块。如果你的包（package）含有两个文件，或许是 “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 块内 “抛出（throw）” 和 捕捉（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!’)
}

然而，如果你把 try-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, …）模式，所有回调函数的第一个参数期待是一个错误对象。

错误 #7：认为数字是整型

数字在 JavaScript中都是浮点型，JS 没有整型。你可能不能预料到这将是一个问题，因为数大到超出浮点型范围的情况并不常见。

Math.pow(2, 53)+1 === Math.pow(2, 53)
不幸的是，在 JavaScript中，这种关于数字的怪异情况远不止于此。尽管数字都是浮点型，对于下面的表达式，操作符对于整型也能正常运行：

5 >> 1 === 2

// true

然而，不像算术运算符那样，位操作符和位移操作符只能操作后 32 位，如同 “整型” 数。例如，尝试位移 “Math.pow(2,53)” 1 位，会得到结果 0。尝试与 1 进行按位或运算，得到结果 1。

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

你可能很少需要处理很大的数，但如果你真的要处理的话，有很多大整型库能对大型精度数完成重要的数学运算，如 node-bigint。

错误 #8：忽略了 Streaming（流） API 的优势

大家都说想建立一个小型代理服务器，它能响应从其它服务器获取内容的请求。作为一个案例，我们将建立一个供应 Gravatar 图像的小型 Web 服务器：

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)

在这个特殊例子中有一个 Node.js 问题，我们从 Gravatar 获取图像，将它读进缓存区，然后响应请求。这不是一个多么糟糕的问题，因为 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：把 Console.log 用于调试目的

在 Node.js 中，“console.log” 允许你向控制台打印几乎所有东西。传递一个对象给它，它会以 JavaScript对象字面量的方式打印出来。它接受任意多个参数，并以空格作为分隔符打印它们。有许多个理由让开发者很想用这个来调试（debug）自己的代码；然而，我强烈建议你避免在真正程序里使用 “console.log” 。你应该避免在全部代码里使用 “console.log” 进行调试（debug），当不需要它们的时候，应注释掉它们。相反，使用专门为调试建立的库，如：debug。

当你开始编写应用程序时，这些库能方便地启动和禁用某行调试（debug）功能。例如，通过不设置 DEBUG 环境变量，能够防止所有调试行被打印到终端。使用它很简单：

// app.js var debug = require(‘debug’)(‘app’) debug(’Hello, %s!’, ‘world’)

为了启动调试行，将环境变量 DEBUG 设置为 “app” 或 “*”，就能简单地运行这些代码了：

DEBUG=app node app.js

错误 #10：不使用管理程序

不管你的 Node.js 代码运行在生产环境还是本地开发环境，一个监控管理程序能很好地管理你的程序，所以它是一个非常有用并值得拥有的东西。开发者设计和实现现代应用时常常推荐的一个最佳实践是：快速失败，快速迭代。

如果发生一个意料之外的错误，不要试图去处理它，而是让你的程序崩溃，并有个监控者在几秒后重启它。管理程序的好处不止是重启崩溃的程序。这个工具允许你重启崩溃的程序的同时，也允许文件发生改变时重启程序。这让开发 Node.js 程序变成一段更愉快的体验。

有很多 Node.js 可用的管理程序。例如：

pm2 forever nodemon supervisor 所有这些工具各有优劣。一些有利于在同一个机器里处理多个应用程序，而其它擅长于日志管理。然而，如果你想开始使用这些程序，它们都是很好的选择