跳到主要内容

Node.js 异步回调要怎样放进请求处理里

· 阅读需 2 分钟
一介布衣
一介布衣
全栈开发者 / 技术写作者

前端开发者刚转到 Node.js 时，经常会在异步这里卡住。页面脚本里也有事件和回调，但放进服务端请求处理后，感受会更强，因为浏览器正在等你返回结果，流程一下就变得更有压力。

先接受“请求不会等你同步写完”​

在 Node.js 里，很多操作都不是一步执行到底然后返回结果，比如读文件、查数据、访问别的服务。这意味着请求到来后，你经常不是立刻 res.end()，而是要先把后续处理交给一个回调。

var fs = require('fs');

fs.readFile('./data.txt', 'utf8', function (err, text) {
  if (err) {
    res.writeHead(500);
    res.end('server error');
    return;
  }

  res.end(text);
});

这个结构在 2013 年的 Node.js 示例里非常常见，因为它直接体现了异步 I/O 的基本写法。

回调真正表达的是“结果稍后回来”​

很多人一开始会把回调当成一种语法技巧，其实它更像是一种流程约定。你先告诉系统“这件事完成之后请来执行这段逻辑”，然后 Node.js 会在结果准备好之后继续往下走。

只要把这个含义理解透，再看文件操作、数据库查询、网络请求，就不会觉得它们只是不同 API，而会发现它们本质上都在处理同一种等待关系。

错误分支一定要先写清楚​

异步代码最容易出问题的地方，通常不是成功流程，而是失败后没有及时结束响应。请求一旦悬在那里，用户看见的就是转圈或者超时。所以回调里先处理 err，不仅是写法习惯，也是稳定性的底线。

小结​

Node.js 异步回调的难点，不是括号多，而是你要开始习惯“请求的结果稍后才回来”这件事。把回调放回请求处理链路里理解，很多抽象概念就会一下子具体起来。