@jinwyp 感谢分享

我看了下这篇文章，发现对 nextTick 的执行时机理解的不正确，应该是这样样的：

1. 进入 event loop 之前，检查一次 nextTickQueue，有，则执行；
2. 在 event loop 的各个阶段，每当一个阶段结束时，都会检查 nextTickQueue，有则执行，没有则进入下一个阶段。

还有就是 poll 阶段的“阻塞/休眠”理解的更深刻了一些：当进入 poll 阶段，而且没有 timers，也没有 setImmediate 时，会被“阻塞”，等待有 Incoming Message，比如网络请求进来。

不知我理解的对不对？

还有就是 event loop 的 check 阶段，node 对于 nextTick 的处理发生了一些变化，以下面代码为例

process.nextTick(function () {
  console.log('nextTick延迟执行1');
});
process.nextTick(function () {
  console.log('nextTick延迟执行2');
});
setImmediate(function () {
  console.log('setImmediate延迟执行1');
  process.nextTick(function () {
	console.log('强势插入');
  });
  var t = new Date();
  while ((new Date()) - t < 200) {

  }
  setTimeout(function () {
	console.log('timeout in immediate1');
  });
});
setImmediate(function () {
  console.log('setImmediate延迟执行2');
});
console.log('正常执行');

Node v0.10.32 中的结果为 正常执行 nextTick延迟执行1 nextTick延迟执行2 setImmediate延迟执行1 强势插入 setImmediate延迟执行2 timeout in immediate1

Node v6 的结果为： 正常执行 nextTick延迟执行1 nextTick延迟执行2 setImmediate延迟执行1 setImmediate延迟执行2 强势插入 timeout in immediate1

在 check 阶段，最早是每当一个setImmediate的callback执行后检查 nextTickQueue，后来改为当前所有 setImmediate 的 callback执行后检查 nextTickQueue。

在朴灵的《深入浅出Node.js》中说的其实是早起的 Node 版本中的逻辑