举个例子:

import fs from 'fs';
import http from 'http';
    
const options = {
  host: 'www.stackoverflow.com',
  port: 80,
  path: '/index.html'
};

describe('deferredExecution', () => {
  it('deferredExecution', (done) => {
    console.log('Start');
    setTimeout(() => console.log('setTimeout 1'), 0);
    setImmediate(() => console.log('setImmediate 1'));
    process.nextTick(() => console.log('nextTick 1'));
    setImmediate(() => console.log('setImmediate 2'));
    process.nextTick(() => console.log('nextTick 2'));
    http.get(options, () => console.log('network IO'));
    fs.readdir(process.cwd(), () => console.log('file system IO 1'));
    setImmediate(() => console.log('setImmediate 3'));
    process.nextTick(() => console.log('nextTick 3'));
    setImmediate(() => console.log('setImmediate 4'));
    fs.readdir(process.cwd(), () => console.log('file system IO 2'));
    console.log('End');
    setTimeout(done, 1500);
  });
});

将给出以下输出

Start // synchronous
End // synchronous
nextTick 1 // microtask
nextTick 2 // microtask
nextTick 3 // microtask
setTimeout 1 // macrotask
file system IO 1 // macrotask
file system IO 2 // macrotask
setImmediate 1 // macrotask
setImmediate 2 // macrotask
setImmediate 3 // macrotask
setImmediate 4 // macrotask
network IO // macrotask

我希望这能帮助你理解其中的区别。

更新:

使用process.nextTick()延迟的回调在任何其他I/O之前运行 事件被触发，而使用setimmediation()，执行被排队 在已经在队列中的任何I/O事件后面。 Node.js设计模式，作者Mario Casciaro(可能是关于Node.js /js最好的书)

简单来说，process.NextTick()将在事件循环的下一个tick执行。但是，setimmediation基本上有一个单独的阶段，该阶段确保在setimmediation()下注册的回调只会在IO回调和轮询阶段之后被调用。

请参考这个链接了解详细解释: https://medium.com/the-node-js-collection/what-you-should-know-to-really-understand-the-node-js-event-loop-and-its-metrics-c4907b19da4c

如果您希望将函数置于已经在事件队列中的任何I/O事件回调之后，请使用setimmediation。使用过程。nextTick可以有效地将函数排在事件队列的头部，以便在当前函数完成后立即执行。

因此，在试图使用递归分解长时间运行的cpu绑定作业的情况下，您现在会希望使用setimmediation而不是process。nextTick将在下一个迭代中排队，否则任何I/O事件回调都没有机会在迭代之间运行。

在回答的评论中，它没有明确地说明nextTick从Macrosemantics转移到Microsemantics。

在节点0.9之前(引入setimmediation时)，nextTick在下一个调用堆栈的开始操作。

从节点0.9开始，nextTick操作在现有调用堆栈的末尾，而setimmediation操作在下一个调用堆栈的开始

查看https://github.com/YuzuJS/setImmediate获取工具和详细信息

你永远不应该使用process中断cpu负荷大的操作。

你不应该使用process.nextTick()中断这样的工作。这样做将导致一个永远不会清空的微任务队列——您的应用程序将永远被困在同一个阶段! ——托马斯·亨特使用Node.js的分布式系统

事件循环的每个阶段包含几个回调:

一旦process.nextTick()被触发，它将始终保持在相同的阶段。

例子

const nt_recursive = () => process.nextTick(nt_recursive);
nt_recursive(); // setInterval will never run

const si_recursive = () => setImmediate(si_recursive);
si_recursive(); // setInterval will run

setInterval(() => console.log('hi'), 10);

在本例中，setInterval()表示应用程序执行的一些异步工作，例如响应传入的HTTP请求。

一旦nt_recursive()函数运行，应用程序就会得到一个永远不会清空的微任务队列，异步工作也永远不会得到处理。

但是替代版本si_recursive()没有同样的副作用。

在检查阶段中调用setimmediation()会将回调添加到下一个事件循环迭代的检查阶段队列，而不是当前阶段的队列。

Case可能使用process.nextTick

使函数处理都异步进行。

function foo(count, callback) {
  if (count <= 0) {
    return process.nextTick(() => callback(new TypeError('count > 0')));
  }
  myAsyncOperation(count, callback);
}

——托马斯·亨特使用Node.js的分布式系统

在这种情况下，使用setimmediation()或process.nextTick()都可以;只是要确保你不会意外地引入递归。

我想我可以很好地解释这个。由于nextTick是在当前操作结束时调用的，因此递归地调用它可能会阻止事件循环继续进行。setimmediation通过在事件循环的检查阶段触发来解决这个问题，允许事件循环正常继续。

   ┌───────────────────────┐
┌─>│        timers         │
│  └──────────┬────────────┘
│  ┌──────────┴────────────┐
│  │     I/O callbacks     │
│  └──────────┬────────────┘
│  ┌──────────┴────────────┐
│  │     idle, prepare     │
│  └──────────┬────────────┘      ┌───────────────┐
│  ┌──────────┴────────────┐      │   incoming:   │
│  │         poll          │<─────┤  connections, │
│  └──────────┬────────────┘      │   data, etc.  │
│  ┌──────────┴────────────┐      └───────────────┘
│  │        check          │
│  └──────────┬────────────┘
│  ┌──────────┴────────────┐
└──┤    close callbacks    │
   └───────────────────────┘

来源:https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/

请注意，检查阶段紧跟在轮询阶段之后。这是因为轮询阶段和I/O回调是对setimmediation的调用最有可能运行的地方。理想情况下，大多数调用都是立即的，只是不像nextTick那样立即，nextTick在每次操作后都会检查，技术上存在于事件循环之外。

让我们看一个setimmediation和process.nextTick区别的小例子:

function step(iteration) {
  if (iteration === 10) return;
  setImmediate(() => {
    console.log(`setImmediate iteration: ${iteration}`);
    step(iteration + 1); // Recursive call from setImmediate handler.
  });
  process.nextTick(() => {
    console.log(`nextTick iteration: ${iteration}`);
  });
}
step(0);

Let's say we just ran this program and are stepping through the first iteration of the event loop. It will call into the step function with iteration zero. It will then register two handlers, one for setImmediate and one for process.nextTick. We then recursively call this function from the setImmediate handler which will run in the next check phase. The nextTick handler will run at the end of the current operation interrupting the event loop, so even though it was registered second it will actually run first.

最后的顺序是:nextTick在当前操作结束时触发，下一个事件循环开始，正常的事件循环阶段执行，setimmediation触发并递归调用step函数重新开始整个过程。当前操作结束，nextTick触发，等等。

上述代码的输出将是:

nextTick iteration: 0
setImmediate iteration: 0
nextTick iteration: 1
setImmediate iteration: 1
nextTick iteration: 2
setImmediate iteration: 2
nextTick iteration: 3
setImmediate iteration: 3
nextTick iteration: 4
setImmediate iteration: 4
nextTick iteration: 5
setImmediate iteration: 5
nextTick iteration: 6
setImmediate iteration: 6
nextTick iteration: 7
setImmediate iteration: 7
nextTick iteration: 8
setImmediate iteration: 8
nextTick iteration: 9
setImmediate iteration: 9

现在让我们将递归调用移到nextTick处理程序中，而不是setimmediation。

function step(iteration) {
  if (iteration === 10) return;
  setImmediate(() => {
    console.log(`setImmediate iteration: ${iteration}`);
  });
  process.nextTick(() => {
    console.log(`nextTick iteration: ${iteration}`);
    step(iteration + 1); // Recursive call from nextTick handler.
  });
}
step(0);

Now that we have moved the recursive call to step into the nextTick handler things will behave in a different order. Our first iteration of the event loop runs and calls step registering a setImmedaite handler as well as a nextTick handler. After the current operation ends our nextTick handler fires which recursively calls step and registers another setImmediate handler as well as another nextTick handler. Since a nextTick handler fires after the current operation, registering a nextTick handler within a nextTick handler will cause the second handler to run immediately after the current handler operation finishes. The nextTick handlers will keep firing, preventing the current event loop from ever continuing. We will get through all our nextTick handlers before we see a single setImmediate handler fire.

上面代码的输出结果是:

nextTick iteration: 0
nextTick iteration: 1
nextTick iteration: 2
nextTick iteration: 3
nextTick iteration: 4
nextTick iteration: 5
nextTick iteration: 6
nextTick iteration: 7
nextTick iteration: 8
nextTick iteration: 9
setImmediate iteration: 0
setImmediate iteration: 1
setImmediate iteration: 2
setImmediate iteration: 3
setImmediate iteration: 4
setImmediate iteration: 5
setImmediate iteration: 6
setImmediate iteration: 7
setImmediate iteration: 8
setImmediate iteration: 9

请注意，如果我们没有中断递归调用并在10次迭代后中止它，那么nextTick调用将继续递归，并且永远不会让事件循环继续到下一个阶段。这就是为什么递归使用nextTick会阻塞，而setimmediation会在下一个事件循环中触发，并且从一个事件循环中设置另一个setimmediation处理程序根本不会中断当前事件循环，允许它继续正常执行事件循环的各个阶段。

希望有帮助!

PS -我同意其他评论者的观点，这两个函数的名称可以很容易地交换，因为nextTick听起来像是要在下一个事件循环中触发，而不是当前循环的结束，而且当前循环的结束比下一个循环的开始更“直接”。哦，好吧，这就是我们得到的API成熟，人们开始依赖现有的接口。