Shulou(Shulou.com)06/02 Report--

Editor to share with you what are common mistakes in nodejs, I believe that most people do not know much about it, so share this article for your reference, I hope you can learn a lot after reading this article, let's go to know it!

Node's ten common errors: 1, blocking the event loop; 2, calling a callback function multiple times; 3, deeply nested callback function; 4, expecting the callback function to be executed synchronously; 5, assigning values to "exports"; 6, throwing an error from the callback; 7, thinking that Number is an integer data format; 8, ignoring the advantages of streaming API, and so on.

This tutorial operating environment: windows7 system, nodejs version 12.19.0, DELL G3 computer.

Since its appearance, Node.js has received a lot of praise and criticism. This kind of debate will go on all the time and will not end any time soon. In these arguments, we often overlook the fact that all languages and platforms are criticized based on some core issues, that is, how we use these platforms. No matter how difficult it is to write reliable code in Node.js and how easy it is to write highly concurrent code, the platform has been around for some time and has been used to create a large number of robust and complex web services. These web services not only have good scalability, but also prove their robustness through their duration on the Internet.

However, like other platforms, Node.js can easily make developers make mistakes. Some of these errors degrade program performance, while others make Node.js unavailable. In this article, we will see ten common mistakes made by beginners to Node.js and how to avoid them.

Error 1: blocking event loop

JavaScript in Node.js (like browsers) provides a single-threaded environment. This means that your program will not have two things running at the same time. Instead, it will asynchronously handle the concurrency caused by the intensive operations of Imap O. For example, when Node.js makes a request to the database to get some data, Node.js can focus on other parts of the program:

/ / 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})

However, in a Node.js instance with thousands of client connections, a small piece of CPU computationally intensive code blocks the event loop, causing all clients to wait. CPU's computationally intensive code includes trying to sort a huge array, running a long function, and so on. For example:

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

Unlike arithmetic operations, however, bit operations and shift operations only work on numbers that are less than the 32-bit maximum. For example, let "Math.pow (2,53)" shift 1 bit always get 0, and let it do bit operation with 1 always get 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

You may rarely deal with such large numbers, but if you need to, there are many large integer libraries that implement large and sophisticated digital operations, such as node-bigint.

Error 8: ignoring the advantages of streaming API

Now we want to create a simple class proxy web server that can respond to and initiate requests by pulling the contents of other web servers. As an example, we create a small web server for Gravatar's image service.

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 ()}) .please (8080)

In this example, we pull the picture from Gravatar, store it in a Buffer, and respond to the request. If the Gravatar pictures are not very large, this is fine. But imagine that if the size of our agent's content is over gigabytes, the better way to deal with it is as follows:

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)})}) .customers (8080)

Here we just pull the picture and simply pipe the response to the client without having to read the complete data into the cache before responding to it.

Error 9: using Console.log for Debug purposes

In Node.js, "console.log" allows you to print anything to the console. For example, if you pass an object to it, it will be printed in the character form of a JavaScript object. It can accept any number of parameters and print them with spaces as delimiters. There are many reasons why developers like to use it to debug their code, but I strongly advise you not to use "console.log" in real-time code. You should avoid using "console.log" to debug all your code, and you should comment them out when you don't need them. You can use a library that specializes in doing this, such as debug.

These libraries provide a convenient way for you to turn on or off specific debug mode when starting the program. For example, with debug, you can prevent any debug method from outputting information to the terminal, as long as you do not set the DEBUG environment variable. It is very easy to use:

/ / app.js var debug = require ('debug') (' app') debug ('Hello,% slots,' world')

To turn on debug mode, simply run the following code to set the environment variable DEBUG to "app" or "*":

DEBUG=app node app.js error 10: do not use monitor

Whether your Node.js code is running in production or your local development environment, a monitor that coordinates your program is well worth having. One suggestion often mentioned by developers for modern programming and development is that your code should have a fail-fast mechanism. If an unexpected error occurs, don't try to deal with it. Instead, let your program crash and let the monitor restart it in a few seconds. The benefits of monitoring programs are not only to restart a crashed program, these tools also allow you to restart a program file when it changes, just like a crash restart. This makes developing Node.js programs a more relaxed and enjoyable experience.

There are too many monitoring programs available for Node.js, such as:

Pm2

Forever

Nodemon

Supervisor

All of these tools have their advantages and disadvantages. Some are good at processing multiple applications on a single machine, while others are good at log management. Anyway, if you want to start writing a program, these are good choices.

The above is all the contents of the article "what are the common mistakes in nodejs?" Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.