共计 5369 个字符，预计需要花费 14 分钟才能阅读完成。
作者：Ivan
本文依据 JavaScript 标准动手，论述了 JS 执行过程在思考时效性和效率衡量中的演变，并通过从 JS 代码运行的根底机制事件队列动手，剖析了 JS 不同工作类型（宏工作、微工作）的差异，通过这些差异给出了详细分析不同工作嵌套的简单 JS 代码执行的剖析流程。
一、事件队列与回调
在应用 JavaScript 编程时，须要用到大量的回调编程。回调，单纯的了解，其实就是一种设置的状态告诉，当某个语句模块执行完后，进行一个告诉到对应办法执行的动作。
最常见的 setTimeout 等定时器，AJAX 申请等。这是因为 JavaScript 单线程设计导致的，作为脚本语言，在运行的时候，语言设计人员须要思考的两件重要的事件，就是执行的实时性和效率。
实时性，就是指在代码执行过程中，代码执行的实效性，以后执行语句工作是否在以后的实效下发挥作用。效率，在这里指的是代码执行过程中，每个语句执行的造成后续执行的提早率。
因为 JavaScript 单线程个性，想要在实现简单的逻辑执行状况下而不阻塞后续执行，也就是保障效率，回调看似是不可避免的抉择。
晚期浏览器的实现和当初可能有许多不同，然而并不会影响咱们用其来了解回调过程。
晚期浏览器设计时，比方 IE6，个别都让页面内相干内容，比方渲染、事件监听、网络申请、文件解决等，都运行于一个独自的线程。此时要引入 JavaScript 管制文件，那 JavaScript 也会运行在于页面雷同的线程上。
当触发某个事件时，有单线程线性执行，这时不仅仅可能是线程中正在执行其余工作，使得以后事件不能立刻执行，更可能是思考到间接执行以后事件导致的线程阻塞影响执行效率的起因。这时事件触发的执行流程，比方函数等，将会进入回调的处理过程，而为了实现不同回调的实现，浏览器提供了一个音讯队列。
当主线上下文内容都程执行实现后，会将音讯队列中的回调逻辑一一取出，将其执行。这就是一个最简略的事件机制模型。
浏览器的事件回调，其实就是一种异步的回调机制。常见的异步过程有两种典型代表。一种是 setTimeout 定时器作为代表的，触发后间接进入事件队列期待执行；一种是 XMLHTTPRequest 代表的，触发后须要调用去另一个线程执行，执行实现后封装返回值进入事件队列期待。在这里并不进行深刻探讨。
由此，咱们失去了 JavaScript 设计的根底线程框架。而宏工作和微工作的差别实现正是为了解决特定问题而在此基础上衍生进去的。而在没有微工作的时代，JavaScript 的执行中并没有所谓异步执行的概念，异步执行是在宿主环境中实现的，也就是浏览器提供了。直至实现了微工作，才能够认为 JavaScript 的代码执行存在了异步过程。
（因为目前宽泛应用的 JavaScript 引擎是 V8，在此咱们已 V8 作为解释对象）
二、(宏)工作和微工作
咱们常在文章中看到，macroTask(宏工作)和 microTask(微工作)的说法。但其实在 MDN[链接]中查看的时候，macroTask(宏工作)这一说法对应于 microTask(微工作)而言的，而对立辨别于 microTask 其实就是一般的 Task 工作。在此咱们能够粗略的认为一般的 Task 工作其实都是 macroTask。
工作的定义：
A task is any JavaScript code which is scheduled to be run by the standard mechanisms such as initially starting to run a program, an event callback being run, or an interval or timeout being fired. These all get scheduled on the task queue.
(任何按规范机制调度进行执行的 JavaScript 代码，都是工作，比方执行一段程序、执行一个事件回调或 interval/timeout 触发，这些都在工作队列上被调度。)
微工作存在的区别定义：
First, each time a task exits, the event loop checks to see if the task is returning control to other JavaScript code. If not, it runs all of the microtasks in the microtask queue. The microtask queue is, then, processed multiple times per iteration of the event loop, including after handling events and other callbacks.
Second, if a microtask adds more microtasks to the queue by calling queueMicrotask(), those newly-added microtasks execute before the next task is run.
(当一个工作存在，事件循环都会查看该工作是否正把控制权交给其余 JavaScript 代码。如果不交予执行，事件循环就会运行微工作队列中的所有微工作。接下来微工作循环会在事件循环的每次迭代中被解决屡次，包含解决完事件和其余回调之后。其次，如果一个微工作通过调用 queueMicrotask(), 向队列中退出了更多的微工作，则那些新退出的微工作会早于下一个工作运行。)
依据定义，能够简略地作出以下了解。
(宏)工作，其实就是规范 JavaScript 机制下的惯例工作，或者简略的说，就是指音讯队列中的期待被主线程执行的事件。在宏工作执行过程中，v8 引擎都会建设新栈存储工作，宏工作中执行不同的函数调用，栈随执行变动，当该宏工作执行完结时，会清空以后的栈，接着主线程继续执行下一个宏工作。
微工作，看定义中与 (宏) 工作的区别其实比较复杂，然而依据定义就能够晓得，其中很重要的一点是，微工作必须是一个异步的执行的工作，这个执行的工夫须要在主函数执行之后，也就是微工作建设的函数执行后，而又须要在以后宏工作完结之前。
由此能够看出，微工作的呈现其实就是语言设计中的一种实时性和效率的衡量体现。当宏工作执行工夫太久，就会影响到后续工作的执行，而此时因为某些需要，编程人员须要让某些工作在宿主环境 (比方浏览器) 提供的事件循环下一轮执行前执行结束，进步实时性，这就是微工作存在的意义。
常见的创立宏工作的办法有 setTimeout 定时器，而常见的属于微工作延长出的技术有 Promise、Generator、async/await 等。而无论是宏工作还是微工作依赖的都是根底的执行栈和音讯队列的机制而运行。依据定义，宏工作和微工作存在于不同的工作队列，而微工作的工作队列应该在宏工作执行栈实现前清空。
这正是剖析和编写相似以下简单逻辑代码所依据的基本原理，并且做到对事件循环的充分利用。
三、依据定义得出的剖析实例
function taskOne() {console.log('task one ...')
setTimeout(() => {Promise.resolve().then(() => {console.log('task one micro in macro ...')
})
setTimeout(() => {console.log('task one macro ...')
}, 0)
}, 0)
taskTwo()}
function taskTwo() {console.log('task two ...')
Promise.resolve().then(() => {setTimeout(() => {console.log('task two macro in micro...')
}, 0)
})
setTimeout(() => {console.log('task two macro ...')
}, 0)
}
setTimeout(() => {console.log('running macro ...')
}, 0)
taskOne()
Promise.resolve().then(() => {console.log('running micro ...')
})依据宏工作、微工作定义和调用栈执行以及音讯队列就能够剖析出 console.log 的输入程序，即所代表的执行程序。
首先，在执行的第一步，全局上下文进入调用栈，也属于惯例工作，能够简略认为此执行也是执行中的一个宏工作。
在全局上下文中，setTimeout 触发设置宏工作，间接进入音讯队列，而 Promise.resolve().then()中的内容进入以后宏工作执行状态下的微工作队列。taskOne 被压入调用栈。当然，因为微工作队列的寄存地位，也是申请于环境对象中，能够认为微工作领有一个独自的队列。
此时以后宏工作并没有完结，taskOne 函数上下文须要被执行。函数外部的 console.log()立刻执行，其中的 setTimeout 触发宏工作，进入音讯队列，taskTwo 被压入调用栈。
此时以后宏工作还没有完结，调用栈中 taskTwo 须要被执行。函数外部的 console.log()立刻执行，其中的 promise 进入微工作的队列，setTimeout 进入音讯队列。taskTwo 出栈执行结束。
此时以后已没有主逻辑执行的代码，而以后宏工作将执行完结，微工作会在以后宏工作实现前执行，所以微工作队列会顺次执行，直到微工作队列清空。首先执行 running micro，输入打印，而后执行 taskTwo 中的 promise，setTimeout 触发宏工作进入音讯队列。
此时曾经清空微工作队列，以后宏工作完结，主线程会到音讯队列进行生产。先执行 running macro 宏工作，间接进行打印，没有对应微工作，以后完结，继续执行 taskOne setTimeout 宏工作，外部执行同理。
因为微工作队列存在工作，在上一个宏工作 taskOne setTimeout 执行完结前，须要执行微工作队列中工作。
接下来所有的宏工作顺次执行。失去最终的输入后果。
咱们能够在 Chrome 外面进行验证。看起来并没有问题。
四、Nodejs 环境中的区别
这是在浏览器搭载 v8 引擎的状况下，咱们验证了宏工作和微工作的执行机理，那在 Nodejs 中运行 JavaScript 代码会有什么不同吗？
应用命令行间接执行 JavaScript 脚本文件，失去了以下后果。
与浏览器的执行输入后果有所不同。这里的 one micro in macro 并没有在一开始执行。这是为什么呢？
尽管 Nodejs 的事件循环有不同于浏览器的六个阶段，然而依照定义标准，这里的宏工作和微工作执行，显著没有遵循微工作辨别差异的第二点，也就是微工作必须在宏工作执行完结前执行。
其实这个问题在之前的业务开发中遇到过。因为微工作执行的时序与定义不符，导致数据呈现了渺小的差别。这里与 Nodejs 版本迭代中的实现无关。
通过命令能够看到以后执行的 Nodejs 版本为 10.16.0。
咱们应用 nvm 切换到更新一些的版本看看执行后果如何。
而后再次应用 Nodejs 执行上述脚本代码。在 11 版本之上咱们失去了和浏览器统一的后果。
从一开始浏览器端就是严格遵循了微工作和宏工作定义进行执行，也就是说，一个宏工作执行实现过程中，就会去检测微工作队列是否有须要执行的工作，即便是微工作嵌套微工作，也会将微工作执行实现，再去执行下一个宏工作。
而通过查看 Nodejs 版本日志发现，在 Nodejs 环境中，在 11 版本之前，同源的工作放在一起进行执行，也就是宏工作队列和微工作队列只有清空一个后才会执行另一个。
就算波及到同源宏工作的嵌套代码，任然会将宏工作一起执行，然而外部的工作则会放到下一个循环中去执行。而在 11 版本后，Nodejs 批改成了与浏览器一样的遵循定义的执行形式。
对于早于 11 版本的 Nodejs 的实现，可能是因为嵌套工作存在的可能性。微工作嵌套微工作可能造成线程中始终处于以后微工作队列执行状态而走不上来，而宏工作的嵌套循环执行，并不会造成内存溢出的问题，因为每个宏工作的执行都是新建的栈。这就是为什么下方的代码会导致栈溢出，而退出 setTimeout 后就不会报错的起因。
既然如此，可能开发人员思考这样情景的时候，不如先把同源工作执行结束，免得在微工作饿死线程的时候，还有未执行实现的宏工作。然而这不符合规范，也显然不是很正当，这样的操作甚至是失误应该交给 JavaScript 的开发者。
function run() {run()
}
run()
function run() {setTimeout(run, 0)
}
run()这兴许是早于 11 版本，Nodejs 实现的一个思考。然而这样并不符合规范，所以我更违心偏向于置信 Nodejs 团队在 11 版本之前的实现存在谬误，而在 11 版本后修复了这个谬误。毕竟如果应用同源执行策略，嵌套中的微工作就曾经失去了时效性，在宏工作都执行实现后的微工作，与宏工作并没有区别。
当然了，目前大部分浏览器都偏向于去符合规范的实现形式，然而任然有一些区别。在应用的过程中，如果须要兼容不容的浏览器还是要更理解这些执行过程，免得呈现难以觉察和查找的问题。在 IE 高版本、FireFox 和 Safari 不同版本中，执行会有些不同，有趣味的能够入手试试，并找出为何不同。
