Node.js/Express中请求为何被setTimeout阻塞？

咱先理清楚你的困惑：Node.js确实是异步非阻塞的，但这事儿只针对异步操作（比如数据库IO、定时器回调这类会丢给事件循环队列的操作）。要是你那10秒延迟是用同步代码实现的，那必然会把整个事件循环卡死，后面的请求根本没机会被处理。

核心原因：你用了同步阻塞代码，不是真异步 #

举个实际的例子，假设你的代码是这样的（模拟你的场景）：

app.get('/', (req, res) => {
  console.log('entering method');
  // 用while循环硬卡10秒的同步延迟
  const start = Date.now();
  while (Date.now() - start < 10000) {
    // 啥也不干，就是占着CPU不撒手
  }
  res.send('Done');
});

这种情况下，Node.js的单线程会被这个while循环完全霸占——事件循环根本抽不出时间去处理第二个请求的回调，得等第一个请求的所有同步代码跑完，才能轮到下一个请求，所以第二个entering method要等10秒才会打印。

但如果换成异步的延迟方式，比如setTimeout，情况就完全不一样了：

app.get('/', (req, res) => {
  console.log('entering method');
  setTimeout(() => {
    res.send('Done');
  }, 10000);
});

这时候，第一个请求进来后，setTimeout会把回调扔进事件循环的定时器队列，然后当前函数就执行完了，线程直接被释放去处理第二个请求——你会看到两个entering method几乎同时冒出来，10秒后两个请求一起返回。

关键知识点：Node.js的单线程事件循环 #

Node.js的主线程是单线程的，所有请求的回调都得在这个线程里跑：

• 如果回调里是同步代码：会一直占着线程不放，直到代码执行完，期间事件循环根本没法处理其他任务，自然就阻塞了后续请求。
• 如果回调里是异步操作：比如IO、定时器、Promise这些，它们会被交给底层的线程池（或者系统API）去处理，当前回调提前结束，线程就能去处理别的请求了，等异步操作干完活儿，对应的回调才会被放到事件循环队列里等着执行。

怎么自查你的问题？ #

看看你那10秒延迟是咋实现的：

• 如果是用了类似sleep的同步函数（比如某些第三方库的同步版本，或者自己写的循环），那肯定是同步阻塞的锅。
• 如果是用了setTimeout或者Promise延迟但还是阻塞，那得看看延迟前后有没有大量的同步计算代码，把线程给占住了。

说白了：Node.js的异步非阻塞是针对IO这类异步操作的，同步代码该卡线程还是会卡，毕竟它是单线程模型嘛。

内容的提问来源于stack exchange，提问作者craigrs84