首章看法，async/await 更为重要是 Promise 下面的句法糖，即使 async/await 的确提供更多了二要的益处。
async/await 让触发器标识符变为并行的形式，进而使标识符极具感染力和时效性。async/await 标准化了触发器程式设计的实战经验；和提供更多了更快的严重错误栈追踪。有关 JS 中触发器程式设计的一点儿发展史
触发器程式设计在 JavaScript 中很常用。每每他们须要展开互联网服务初始化、文档出访或资料库操作形式时，虽然词汇是Renderscript的，但触发器性是他们避免界面被堵塞的形式。
在 ES6 以后，反弹是猿们处置触发器程式设计的形式。他们抒发天数敏感性（即异步操作形式的继续执行次序）的惟一形式是将两个反弹冗余在另两个反弹中，这引致了简而言之的反弹冥界。
Es6 中导入了 Promise，它是两个用于触发器操作形式的一流对象，他们可以轻松地传递、组合、聚合和应用转换。天数上的依赖性通过then形式链干净地抒发出来。
有了 Promise 这个强大的伙伴，听起来触发器程式设计在 JS 这是两个已经解决的问题，对吗？
恩，还没有，即使有时候 Promise 的级别太低了，不太适合使用。
有时 Promise 的级别太低，不适合使用
虽然出现了 Promise，但在 JS 中仍然须要两个更高级别的词汇结构来展开触发器程式设计。
他们来看个例子， 假设他们须要某个函数在某个天数间隔轮询两个API。当达到最大重试次数时，它就会解析为null。
下面是 Promise 的一种解决方案：
let count = 0; function apiCall() { return new Promise((resolve) => // a在第6次重试时，它被解析为 “value”。 count++ === 5 ? resolve(value) : resolve(null) ); } function sleep(interval) { return new Promise((resolve) => setTimeout(resolve, interval)); } function poll(retry, interval){ return new Promise((resolve) => { // 为了简洁起见，跳过严重错误处置 if (retry === 0) resolve(null); apiCall().then((val) => { if (val !== null) resolve(val); else { sleep(interval).then(() => { resolve(poll(retry – 1, interval)); }); } }); }); } poll(6, 1000).then(console.log); // value这种解决方案的直观性和时效性取决于人们对Promise的熟悉程度，和Promise.resolve 如何 “平铺” Promise 和递归。对我来说，这不是写这样两个函数的最可读的形式。
使用 async/await
他们用async/await 句法重写上述解决方案：
async function poll(retry, interval) { while (retry >= 0) { const value = awaitapiCall().catch((e) => {}); if (value !== null) return value; await sleep(interval); retry–; } return null; }我想大多数人都会觉得下面的解决方案更有时效性，即使他们能够使用所有正常的词汇结构，如循环、触发器操作形式的 try-catch 等。
这可能是 async/await的最大卖点–使他们能够以并行的形式编写异步标识符。另一方面，这可能是对async/await
顺便说一下，await甚至有正确的操作形式符优先级，所以await a + await b 等于(await a) + (await b)，而不是让他们说await (a + await b)。
async/await 在并行和触发器标识符中提供更多了标准化的体验
async/await的另两个益处是，await自动将任何非Promise（non-thenables）包装成 Promises 。await的语义等同于Promise.resolve，这意味着可以 await 任何东西:
function fetchValue() { return 1; } async function fn() { const val = await fetchValue(); console.log(val); // 1 } // 下面等同于下面 function fn() { Promise.resolve(fetchValue()).then((val) => { console.log(val); // 1 }); }如果他们将 then 形式附加到从 fetchValue 返回的数字 1 上，就会出现以下严重错误。
function fetchValue() { return 1; } function fn() { fetchValue().then((val) =>{console.log(val); }); } fn(); // ❌ Uncaught TypeError: fetchValue(…).then is not a function最后， 从 async 函数返回的任何东西都是两个 Promise:
Object.prototype.toString.call((async function () {})()); // [object Promise]async/await 提供更多更快的严重错误栈追踪
V8工程师Mathias写了一篇名为Asynchronous stack traces: why await beats Promise#then() 的文章，介绍了为何与 Promise相比，引擎更容易捕捉和存储 async/await 的栈追踪。事例如下：
async function foo() { await bar(); return value; } function bar() { throw new Error(BEEP BEEP); } foo().catch((error) => console.log(error.stack));// Error: BEEP BEEP // at bar (<anonymous>:7:9) // at foo (<anonymous>:2:9) // at <anonymous>:10:1async 版本正确地捕获了严重错误栈追踪。
他们再来看看 Promise 版本。
function foo() { return bar().then(() => value); } function bar(){ return Promise.resolve().then(() => { throw new Error(BEEP BEEP); }); } foo().catch((error) => console.log(error.stack)); // Error: BEEP BEEP at <anonymous>:7:11栈追踪丢失。从匿名的箭头函数切换到命名的函数声明有一点儿帮助，但帮助不大:
function foo() { return bar().then(() => value); } function bar() { return Promise.resolve().then(function thisWillThrow() { throw new Error(BEEP BEEP); }); } foo().catch((error) => console.log(error.stack));// Error: BEEP BEEP // at thisWillThrow (<anonymous>:7:11)对async/await常用反对意见
对 async/await 主要有两种常用的反对意见。
首先，当独立的触发器函数初始化可以用Promise.all并发处置时，如果他们还大量使用async/await可能会引致滥用，这样会造成开发者不去试图了解 Promise 的幕后是如何工作，而只是一味地使用async/await。
第二种情况更为微妙。一些函数式程式设计爱好者认为 async/await 会招致命令式程式设计。从 FP 程序员的角度来看，能够使用循环和 try catch并不是一件好事，即使这些词汇结构意味着副作用，并鼓励使用不那么理想的严重错误处置。
我对这种说法待保留意见。FP程序员理所当然地关心他们程序中的确定性。他们希望对自己的标识符有绝对的信心。为了达到这个目的，须要一个复杂的类型系统，其中包括Result等类型。但我不认为async/await本身与FP不相容。
无论如何，对于大多数人来说，包括我在内，FP仍然是一种后天的味道（虽然我的确认为FP超级酷，而且我正在慢慢学习它）。async/await提供更多的正常控制流语句和try catch严重错误处置，对于他们在 JavaScript 中协调复杂的触发器操作形式是非常宝贵的。这正是为何说 “async/await只是一种句法糖” 是一种轻描淡写的说法。
