唯一比不知道代码为什么崩溃更可怕的事情是，不知道为什么一开始它是工作的！
在 ECMA 规范的最近几次版本里不断有新成员加入，尤其在处理异步的问题上，更是不断推陈出新。然而，我们在享受便利的同时，也应该了解异步到底是怎么一回事。
现在与将来
JavaScript 是单线程的，一次只能专注于一件事。如果浏览器只靠 JavaScript 引擎线程来完成所有工作，先不说能不能搞定，即使可以，那也会花费很长时间。幸好在浏览器里 JavaScript 引擎并不孤单，还有 GUI 渲染线程、事件触发线程、定时触发器线程、异步http请求线程等其它线程。这些线程之间的协作才有了我们看到的浏览器界面效果（远不止这些）。
(盗了一张图)
一个程序在执行过程中可能会有等待用户输入、从数据库或文件系统中请求数据、通过网络发送并等待响应，或是以固定时间间隔执行重复任务（比如动画）等情况。（这些情况，当下是无法得出结果的，但是一旦有了结果，我们知道需要去做些什么。）
JavaScript 引擎不是一个人在战斗，它把以上的任务交给其它线程，并计划好任务完成后要做的事，JavaScript 引擎又可以继续做自己的事了。从这里可以看出，一个程序的运行包括两部分，现在运行和将来运行。而现在运行和将来运行的关系正是异步编程的核心。
let params = {type:'asynchronous'}
let response = ajax(params,'http://someURL.com'); // 异步请求
if (!response) throw '无数据！';以上代码肯定会抛错的，异步请求任务交出去之后，程序会继续运行下去。由于ajax(...) 是异步操作，即使立刻返回结果，当下的 response 也不会被赋值。一个是现在，一个是将来，两者本就不属于一个时空的。
事件循环
现在和将来是相对的，等将来的时刻到了，将来也就成为了现在。
JavaScript 引擎运行在宿主环境中，宿主环境提供了一种机制来处理程序中多个块的执行，且执行每个块时调用 JavaScript 引擎，这种机制被称为事件循环。即，JavaScript 引擎本身并没有时间的概念，只是一个按需执行 JavaScript 任意代码片段的环境。
“事件”（JavaScript 代码执行）调度总是由包含它的环境进行。
点击图片进入或点此进入：
一个 JavaScript 运行时包含了一个待处理的消息队列。每一个消息都关联着一个用以处理这个消息的函数。
在事件循环期间的某个时刻，运行时从最先进入队列的消息开始处理队列中的消息。为此，这个消息会被移出队列，并作为输入参数调用与之关联的函数。
while (queue.waitForMessage()) {queue.processNextMessage();
}一旦有事件需要进行，事件循环就会运行，直到队列清空。事件循环的每一轮称为一个 tick。用户交互，IO 和定时器会向事件队列中加入事件。
(又盗了一张图)
任务队列
任务队列（job queue）建立在事件循环队列之上。（Promise 的异步特性就是基于任务。）
最好的理解方式，它是挂在事件循环队列的每个tick之后的一个队列。在事件循环的每个tick中，可能出现的异步动作不会导致一个完整的新事件添加到事件循环队列中，而会在当前 tick 的任务队列末尾添加一个项目（一个任务）。
即，由 Call Stack 生成的任务队列会紧随其后运行。
Promise.resolve().then(function promise1 () {console.log('promise1');
})
setTimeout(function setTimeout1 (){console.log('setTimeout1');Promise.resolve().then(function promise2 () {console.log('promise2');})
}, 0)setTimeout(function setTimeout2 (){
console.log('setTimeout2');Promise.resolve().then(function promise3 () {console.log('promise3');setTimeout(function setTimeout3 () {console.log('setTimeout3');})Promise.resolve().then(function promise4 () {console.log('promise4');})})
}, 0)
// promise1
// setTimeout1
// promise2
// setTimeout2
// promise3
// promise4
// setTimeout3异步回调
被作为实参传入另一函数，并在该外部函数内被调用，用以来完成某些任务的函数，称为回调函数。回调函数经常被用于继续执行一个异步完成后的操作，它们被称为异步回调。立即执行的称之为同步回调。
回调函数是事件循环“回头调用”到程序中的目标，队列处理到这个项目的时候会运行它。
回调是 JavaScript 语言中最基础的异步模式。
生活中，我们喜欢和有条理的人打交道，因为我们的大脑习惯了这种思维模式。然而回调的使用打破了这种模式，因为代码的嵌套使得我们要在不同块间切换。嵌套越多，逻辑越复杂，我们也就越难理解和处理代码，尤其在表达异步的方式上。
(又盗了一张图)
除了嵌套的问题，异步回调还存在一些信任问题。
- 回调性质的不确定
- 调用回调方式不确定（没调用，重复调用等）
- ......
针对第一点的建议是：永远异步调用回调，即使就在事件循环的下一轮，这样，所有回调都是可预测的异步调用了。
在理解这个建议之前，我们首先了解下控制反转，控制反转就是把自己程序一部分的执行控制交个某个第三方。
let a = 0; // A
thirdparty(() => {console.log('a', a); // B
})
a++; // CA 和 C 是现在运行的，B 虽然代码是我们的，但是却受制于第三方，因为我们无法确定它是现在运行还是将来运行的。这里的回调函数可能是同步回调也可能是异步回调。a 是 0 还是 1，都有可能。
// 同步回调
const thirdparty = cb => {cb();
}
// 异步回调
const thirdparty = cb => {setTimeout(() => cb(), 0);
}所以，永远异步调用回调，可预测。
function asyncify(fn) {let func = fn;let t = setTimeout(() => {t = null;if (fn) fn();}, 0);fn = null;return () => {if (t) {fn = func.bind(this, ...arguments);} else {func.apply(this, arguments);}}
}let a = 0;
thirdparty(asyncify(() => {console.log('a', a);
}))
a++;
// 1
