讨论 `JS` 模块的 `Top-level await` (ES2022) 如何改变模块初始化流程和潜在的死锁问题。

大家好，各位未来的代码大师们，欢迎来到今天的模块魔法课堂！ 今天我们要聊的是一个听起来很酷，用起来更酷的 JavaScript 特性：Top-level await (顶级 await)。 这东西就像给你的模块打了一针鸡血，让它们在初始化的时候可以玩点更刺激的。

那么，Top-level await 到底是个什么玩意儿？ 简单来说，它允许你在 ES 模块的顶层，也就是模块的最外层作用域，直接使用 await 关键字。 这意味着你的模块可以在加载的时候暂停执行，等待一个 Promise 对象 resolve 之后再继续。

这听起来可能有点抽象，我们先来看看没有 Top-level await 的日子是怎么过的。

没有 Top-level await 的日子：模块初始化流程与痛点

在 ES2022 之前，如果你的模块需要在初始化的时候进行异步操作，比如从服务器获取配置信息、读取文件等等，你只能使用 IIFE (Immediately Invoked Function Expression，立即执行函数表达式) 或者在模块内部定义异步函数，然后在模块加载后手动调用它们。

举个例子：

// config.js (没有 Top-level await 的时代)
let config = null;

(async () => {
  const response = await fetch('/api/config');
  config = await response.json();
})();

export function getConfig() {
  return config;
}

// app.js
import { getConfig } from './config.js';

// 稍等片刻，config 可能还是 null
setTimeout(() => {
  console.log(getConfig()); // 可能是 null，也可能是配置对象
}, 100);

在这个例子中，config.js 模块使用 IIFE 来异步获取配置信息。 但是，由于 IIFE 是异步执行的，config 变量在模块加载的时候可能还没有被初始化，导致 app.js 在调用 getConfig() 的时候可能会得到 null。 这就需要在 app.js 中使用 setTimeout 或者其他方式来等待 config 被初始化，增加了代码的复杂性和不确定性。

这种方式存在以下几个痛点：

• 代码冗余： 需要使用 IIFE 或者其他方式来处理异步操作。
• 时序问题： 需要手动处理异步操作完成的时机，容易出现时序问题。
• 可读性差： 代码结构比较复杂，可读性较差。

Top-level await：模块初始化的新姿势

有了 Top-level await，上面的代码就可以简化成这样：

// config.js (有了 Top-level await 的时代)
const response = await fetch('/api/config');
const config = await response.json();

export function getConfig() {
  return config;
}

// app.js
import { getConfig } from './config.js';

console.log(getConfig()); // 保证是配置对象

看到了吗？ config.js 模块直接在顶层使用了 await 关键字，等待 fetch 请求完成并解析 JSON 数据之后，才继续执行。 这样就保证了 config 变量在模块加载完成的时候已经被初始化，app.js 在调用 getConfig() 的时候可以得到正确的配置对象。

Top-level await 的优势显而易见：

• 代码简洁： 无需使用 IIFE 或者其他方式来处理异步操作。
• 时序保证： 模块加载的时候会自动等待异步操作完成，避免时序问题。
• 可读性好： 代码结构清晰，可读性好。

Top-level await 的适用场景

Top-level await 在以下场景中非常有用：

• 动态导入： 在模块加载的时候动态导入其他模块。
• 读取配置文件： 在模块加载的时候从服务器或者本地文件读取配置文件。
• 连接数据库： 在模块加载的时候连接数据库。
• 初始化 SDK： 在模块加载的时候初始化 SDK。

总之，任何需要在模块初始化的时候进行异步操作的场景，都可以考虑使用 Top-level await。

Top-level await 的潜在风险：死锁问题

Top-level await 虽然好用，但是也存在一些潜在的风险，其中最主要的就是死锁问题。

死锁是指两个或多个模块相互依赖，并且都在等待对方完成初始化，导致程序无法继续执行的状态。

举个例子：

// moduleA.js
import { valueB } from './moduleB.js';

console.log('moduleA is loading');
const valueA = await Promise.resolve(valueB * 2);
console.log('moduleA loaded');

export { valueA };

// moduleB.js
import { valueA } from './moduleA.js';

console.log('moduleB is loading');
const valueB = await Promise.resolve(valueA * 3);
console.log('moduleB loaded');

export { valueB };

在这个例子中，moduleA.js 依赖 moduleB.js，而 moduleB.js 又依赖 moduleA.js。 当模块加载器加载 moduleA.js 的时候，它会遇到 await Promise.resolve(valueB * 2)，需要等待 valueB 被初始化。 而 valueB 的初始化又依赖 valueA，导致两个模块相互等待，形成死锁。

为什么会发生死锁？

当模块系统遇到 import 语句时，它会尝试加载被导入的模块。 如果被导入的模块也包含 import 语句，模块系统会递归地加载这些模块。 在这个过程中，如果出现了循环依赖，并且循环依赖中的模块都使用了 Top-level await，就可能会发生死锁。

如何避免死锁？

避免死锁的关键是打破循环依赖。 以下是一些常用的方法：

1. 避免循环依赖： 尽量避免模块之间的循环依赖。 重新设计模块的结构，将公共的逻辑提取到单独的模块中，减少模块之间的依赖关系。

2. 延迟依赖： 如果无法避免循环依赖，可以尝试延迟依赖。 将依赖关系放到函数内部，在函数调用的时候才加载依赖的模块。

   // moduleA.js
   export async function getValueA() {
     const { valueB } = await import('./moduleB.js');
     return valueB * 2;
   }
   
   // moduleB.js
   export async function getValueB() {
     const { valueA } = await import('./moduleA.js');
     return valueA * 3;
   }

   在这个例子中，moduleA.js 和 moduleB.js 之间的依赖关系被延迟到了 getValueA() 和 getValueB() 函数内部。 这样就可以避免在模块加载的时候发生死锁。

3. 使用 import() 动态导入： 动态导入可以打破循环依赖，因为动态导入返回的是一个 Promise 对象，可以在需要的时候才加载依赖的模块。

   // moduleA.js
   let valueA;
   import('./moduleB.js').then(({ valueB }) => {
     valueA = valueB * 2;
     console.log('moduleA loaded');
   });
   
   export { valueA };
   
   // moduleB.js
   let valueB;
   import('./moduleA.js').then(({ valueA }) => {
     valueB = valueA * 3;
     console.log('moduleB loaded');
   });
   
   export { valueB };

   需要注意的是，使用动态导入时，需要确保在使用 valueA 和 valueB 之前，它们已经被初始化。

4. 使用 try...catch 包裹 await 语句： 在使用 await 的时候，可以使用 try...catch 语句来捕获异常。 这样可以防止因为某个模块加载失败而导致整个程序崩溃。

   // moduleA.js
   let valueA;
   try {
     const { valueB } = await import('./moduleB.js');
     valueA = valueB * 2;
     console.log('moduleA loaded');
   } catch (error) {
     console.error('moduleA failed to load:', error);
   }
   
   export { valueA };

Top-level await 的一些限制

• 只能在 ES 模块中使用： Top-level await 只能在 ES 模块中使用，不能在 CommonJS 模块中使用。
• 浏览器支持： Top-level await 需要浏览器支持。 大部分现代浏览器都支持 Top-level await，但是一些老版本的浏览器可能不支持。

Top-level await 的总结

Top-level await 是一个非常强大的特性，可以简化模块初始化流程，提高代码的可读性。 但是，也需要注意 Top-level await 带来的潜在风险，特别是死锁问题。 在使用 Top-level await 的时候，需要仔细考虑模块之间的依赖关系，避免循环依赖，并使用适当的措施来防止死锁。

为了更清晰的总结，我们用一个表格来对比有无 Top-level await 的区别

特性/问题	没有 Top-level await	有 Top-level await
代码复杂度	较高，需要 IIFE 或其他异步处理方式	较低，直接使用 await
时序控制	手动控制，容易出错	自动控制，更可靠
可读性	较差	更好
死锁风险	循环依赖可能导致死锁，但表现形式可能不明显	循环依赖更容易导致死锁，更容易被发现，也需要更小心
适用场景	任何需要异步初始化的模块，但实现方式较为繁琐	任何需要异步初始化的模块，更方便简洁
浏览器兼容性	兼容性好，无需特别考虑	需要考虑浏览器兼容性，部分老版本浏览器不支持
代码示例	javascript <br> let config = null; <br> (async () => { <br> const response = await fetch('/api/config'); <br> config = await response.json(); <br> })(); <br> export function getConfig() { <br> return config; <br> } | javascript <br> const response = await fetch('/api/config'); <br> const config = await response.json(); <br> export function getConfig() { <br> return config; <br> }
避免死锁的方法	避免循环依赖，延迟初始化	除了避免循环依赖和延迟初始化，还可以使用动态 import()

总而言之，Top-level await 就像一把双刃剑，用得好，能让你的代码飞起来；用不好，可能会让你陷入死锁的泥潭。 掌握好 Top-level await 的使用方法，才能真正发挥它的威力，写出更优雅、更高效的 JavaScript 代码。

希望今天的讲座对大家有所帮助！ 祝大家代码写得飞起，Bug 少得可怜！ 下课！