为什么js里使用了await的方法必须定义成async的?

发布网友 发布时间：2024-10-02 11:43

我来回答

共1个回答

热心网友 时间：2024-10-19 07:26

在JavaScript中，async/await 和 Generator 的概念紧密相关。async/await 实际上是对 Generator 的一种语法糖，它被设计为具有自动 spawn 功能的 Generator，其特殊标记（async）的使用原因类似于 Generator 需要特殊标记（*）。

我们首先需要了解为什么 Generator 不能直接使用 function 而是采用了一个 function * 的怪异语法。追溯到 Generator 语法最早的版本实现，可以发现，Mozilla JS 1.7 的 Generator 并不需要特殊标记，仅是一个包含 yield 语句的特殊函数。然而，当 Mozilla 的开发者计划将这一语法特性标准化时，考虑到了以下几点原因：在非严格模式下，await 不是保留字以及从可读性的角度出发。

随着现代前端代码逐渐迁移到了 ES Module（默认为严格模式），标准委员会也在逐步扩大 await 的使用场景，并引入了 top-level await 提案。这一提案允许在 Module 环境下直接使用 await，然而实现这一功能时需要注意的不仅有词法解析、语法设计等，还有一系列实现细节上的小问题，如潜在的死锁问题、可能影响模块加载时间以及与 CommonJS 模块的兼容性。

标准委员会最终决定将 top-level await 从 await/async 提案中独立出来，进行单独标准化，并与各个执行环境（loader）进行协作。在后续的讨论中，还引发了一次较大讨论：“Top-level await is a footgun”。尽管提案已进展到了 Stage 3，建议阅读提案的 FAQ 部分，但进入标准的进程仍面临困难，TC39 成员代表已表达强烈反对。

从这一提案的经历中，可以得出另一个相比在任意情况下都允许 await，将其限制在 async function {} 块中，实现起来更为简便。出于实用主义的考虑，将限制添加到功能实现中，更符合广大 JavaScript 开发者的利益。

在最初的设想中，async function 实际上等同于 function { return spawn(function*() ); }。在非严格模式下，函数 f() { var yield = 1; return yield; } 是合法的，这反映了早期版本对语法的考虑。在当时的观点中，有人持有“ES6 不需要 opt-in”的立场，但现在回过头来看，"use strict" 和 script type="module" 这种形式的 opt-in 确实影响了用户接受度，因此标准委员会整体倾向于在 ES6 新特性中尽可能兼容旧代码。

在早期版本的 async function 草案中，语法上的考虑被提及，反映了标准制定过程中的复杂性和权衡。await 在非严格模式下作为保留字，以及在严格模式下的直接使用，体现了 JavaScript 标准制定者在设计语法时的深思熟虑。

热心网友 时间：2024-10-19 07:25

在JavaScript中，async/await 和 Generator 的概念紧密相关。async/await 实际上是对 Generator 的一种语法糖，它被设计为具有自动 spawn 功能的 Generator，其特殊标记（async）的使用原因类似于 Generator 需要特殊标记（*）。

我们首先需要了解为什么 Generator 不能直接使用 function 而是采用了一个 function * 的怪异语法。追溯到 Generator 语法最早的版本实现，可以发现，Mozilla JS 1.7 的 Generator 并不需要特殊标记，仅是一个包含 yield 语句的特殊函数。然而，当 Mozilla 的开发者计划将这一语法特性标准化时，考虑到了以下几点原因：在非严格模式下，await 不是保留字以及从可读性的角度出发。

随着现代前端代码逐渐迁移到了 ES Module（默认为严格模式），标准委员会也在逐步扩大 await 的使用场景，并引入了 top-level await 提案。这一提案允许在 Module 环境下直接使用 await，然而实现这一功能时需要注意的不仅有词法解析、语法设计等，还有一系列实现细节上的小问题，如潜在的死锁问题、可能影响模块加载时间以及与 CommonJS 模块的兼容性。

标准委员会最终决定将 top-level await 从 await/async 提案中独立出来，进行单独标准化，并与各个执行环境（loader）进行协作。在后续的讨论中，还引发了一次较大讨论：“Top-level await is a footgun”。尽管提案已进展到了 Stage 3，建议阅读提案的 FAQ 部分，但进入标准的进程仍面临困难，TC39 成员代表已表达强烈反对。

从这一提案的经历中，可以得出另一个相比在任意情况下都允许 await，将其限制在 async function {} 块中，实现起来更为简便。出于实用主义的考虑，将限制添加到功能实现中，更符合广大 JavaScript 开发者的利益。

在最初的设想中，async function 实际上等同于 function { return spawn(function*() ); }。在非严格模式下，函数 f() { var yield = 1; return yield; } 是合法的，这反映了早期版本对语法的考虑。在当时的观点中，有人持有“ES6 不需要 opt-in”的立场，但现在回过头来看，"use strict" 和 script type="module" 这种形式的 opt-in 确实影响了用户接受度，因此标准委员会整体倾向于在 ES6 新特性中尽可能兼容旧代码。

在早期版本的 async function 草案中，语法上的考虑被提及，反映了标准制定过程中的复杂性和权衡。await 在非严格模式下作为保留字，以及在严格模式下的直接使用，体现了 JavaScript 标准制定者在设计语法时的深思熟虑。