原文地点（英）：
https://jakearchibald.com/201…
当我通知Matt Gaunt（作者的同事），我正在经营写一篇关于在浏览器事宜轮回（event loop）系统中微使命（ microtask ）的行列和实行的文章时，他说：“真话通知你Jake，我对这篇文章是不会感兴趣的”。好吧，不管怎样，既然我已写了那就让我们坐下来好好享用它，好吗？
事实上，假如视频更相符你的胃口，那末Philips Roberts 在JSConf上关于event loop的演讲会是很好的参考（该演讲不触及微使命（microtask），然则对事宜轮回的其他部份都讲得异常好），闲话少说，最先我们的内容。
以下是一小段JavaScript：
console.log('script start');
setTimeout(function() {
console.log('setTimeout');
}, 0);
Promise.resolve().then(function() {
console.log('promise1');
}).then(function() {
console.log('promise2');
});
console.log('script end');想想看控制台会依据什么样的递次打印效果呢？
准确的答案是：script start, script end, promise1, promise2, setTimeout，然则在差别的浏览器上效果能够会有所差别。
Microsoft Edge, Firefox 40, iOS Safari和桌面版Safari 8.0.8会在promise1,promise2之前打印出setTimeout，虽然这多是浏览器厂商间各自合作的效果，但这难免有些新鲜，因为Firefox 39和Safari 8.0.7获得的效果始终是准确的。
为何会是如许
为了搞清楚启事，你须要邃晓事宜轮回（event loop）是怎样处置惩罚使命（tasks）和微使命（microtasks）的.当这些名词第一次涌现的时刻，你能够会觉得头疼，没紧要，深呼吸…
每个”线程”都具有属于本身的事宜轮回（event loop）,也就意味着每个web worker都邑存在自有的事宜轮回并自力运转互不滋扰。但是一切同源窗口之间同享一个事宜轮回（event loop），如许它们就能够够同步通讯了（译者注：依据HTML5.2范例，事宜轮回分两种，一种是浏览器上下文的，一种是web worker的）。事宜轮回（event loop）老是不停的运转，实行行列中的使命（task）。一个事宜轮回存在多个使命源，这确保了使命在特定使命源的实行递次（译者注：同一个使命源的使命将被添加到雷同使命行列，差别使命源的使命能够被添加到差别使命行列），然则在每一次的轮回中，浏览器会自立挑选哪一个源的使命优先实行，这确保了一些机能敏感的使命的优先级，比方用户输入。
使命（tasks，译者注：也叫macro-task）被放到使命源中，浏览器内部实行转移到JavaScript/DOM范畴，而且确保这些 tasks顺次实行。在tasks实行时期，浏览器能够更新衬着。来自鼠标点击的事宜回调须要部署一个task，剖析HTML和setTimeout一样须要。
setTimeout等待了给定的耽误时间以后就会为它的回调建立一个新的使命。这就是为何setTimeout在script end以后打印script start，因为script end是归属于第一个使命，而setTimeout对应的是另一个使命，至此，我们将近搞清楚了，我须要你们有充足的耐烦看完下一个部份
微使命（Microtasks）行列一般用于寄存一些使命，这些使命应当在正在实行的剧本以后马上实行，比方对一批行动作出反应，或许操纵异步实行防止建立全部新使命形成的机能糟蹋。每次事宜轮回中，假如没有其他JavaScript运转而且使命（task）都实行终了了，那末微使命就会在回调以后被实行。在微使命中列队的任何其他微使命将被添加到行列的末端并举行处置惩罚。微使命包含 MutationObserver、Promise的回调（译者注：微使命包含：process.nextTick（Nodejs）, Promises, Object.observe, MutationObserver;使命（tasks）包含：script（团体代码）, setTimeout, setInterval, setImmediate, I/O, UI rendering）。
一个settled状况的promise（直接挪用resolve或许reject）或许已变成settled状况(异步要求被settled)的promise，会马上将它的callback（then）放到microtask行列内里。这就能够保证promise的回调是异步的，即使promise已变成settled状况。因而一个已settled的promise挪用.then(yey,nay)时将马上把一个microtask使命到场microtasks使命行列。这就是为何 promise1 和 promise2 在 script end 以后打印，因为正在运转的代码必须在处置惩罚 microtasks 之前完成。promise1 和 promise2 在 setTimeout 之前打印，因为 microtasks 老是在下一个 task 之前实行。
让我们一步一步剖析，（译者注：跳转到原文step by step示例,这对明白本文异常有效）
为何在一些浏览器上的效果会有差别呢？
一些浏览器打印出来的效果是：script start，script end，setTimeout，promise1，promise2。这些浏览器在promise回调之前挪用了setTimeout。这很多是浏览器把promise回调当作是新使命(task )的一部份而不是微使命(microtask)。
这类毛病某种程度上是能够被谅解的，因为promises范例来源于ECMAScript而不是HTML。ECMAScript定义了相似微使命的“jobs”观点，然则除了一些隐约的邮件议论以外，这类关联（jobs和microtasks）并不明白。但promises应当作为微使命的一部份这是广泛的共鸣。
把promise当作是使命将会致使一些机能题目，回调能够没有必要因为某些相干使命（比方衬着）而被耽误。因为与其他使命源的交互这也会致使一些不确定性，而且会中缀与其他Api的交互。
把promise归类为微使命已是很迫切的事变了。Webkit（Safari内核）一直都在做准确的事变，我想Safari最终会处理这和题目，事实上，Firefox43已修复了这个题目。
真正风趣的是，Safari和Firefox在这里都阅历了一次回归，从那以后题目就被修复了。我想知道这是不是一个偶合。
译者注
- task -> microtask -> ui render
- 关于promise而言，决定后（resolve或reject）才会把then回调推入microtaks行列
