ES Module 的顶层 await 仅在明确的 ESM 环境中合法，需满足模块启用条件（如 type="module"、.mjs 后缀或 "type": "module"），其执行会阻塞模块初始化及依赖导入，导出须在 await 后且静态可分析，错误必须内部捕获。
ES Module 的顶层 await 不是“写了就能跑”的语法糖，它依赖明确的执行上下文。只有在真正的 ES 模块环境中，顶层 await 才会被引擎识别并正确求值；否则直接报 SyntaxError: await is only valid in async functions and the top level bodies of modules。
必须满足的模块启用条件
顶层 await 只在 ES 模块（ESM）中合法，CommonJS、普通 script 或 Node.js 默认 CommonJS 模式下均不支持。
- 浏览器中：HTML 必须用
<script type="module" src="main.js"></script>加载，不能省略type="module" - Node.js 中：需满足三者之一——文件后缀为
.mjs、package.json中设"type": "module"、或启动时加--input-type=module - REPL 环境例外：需显式启用
node --experimental-repl-await，但仅限交互式输入，不影响文件执行
执行顺序与模块阻塞行为
含顶层 await 的模块会暂停自身初始化，直到 Promise 完成，同时阻塞所有静态 import 它的模块——这是 ESM 异步初始化语义的核心表现。
- 多个顶层 await 按代码顺序串行执行，不会自动并发；如需并行，应显式用
Promise.all([a(), b()]) - 模块缓存仍生效：同一模块多次 import 不会重复执行顶层 await 逻辑
- 不能在动态
import()的回调里使用顶层 await，但可在其返回的 Promise 上await（例如：const mod = await import('./x.js')）
导出与错误处理的硬性规则
顶层 await 改变了模块导出时机，也放大了错误影响范围，必须严格遵循静态可分析和内部捕获原则。
- 导出语句（
export/export default）必须出现在 await 之后，且不能被 if/try 等条件包裹 - fetch 类操作要手动检查
response.ok，否则非 2xx 响应会直接 reject，导致模块加载失败 - 异常必须在模块内
try/catch，外部无法拦截；未捕获时模块状态变为errored，所有依赖它的import都会拒绝
常见陷阱与规避方式
看似方便的顶层 await，实际容易因环境错配或设计疏忽引发静默失败或启动卡顿。
- 避免在顶层 await 未设 timeout 的网络请求，建议搭配
AbortSignal.timeout()或自定义超时逻辑 - 带 Cookie 或认证头的请求，务必传
{ credentials: 'include' }，否则可能静默 401 - 严禁循环依赖：A.js 顶层 await 后 import B.js，B.js 又 import A.js → 模块图死锁
- 不要用 IIFE 模拟顶层 await（如
(async () => { ... })()），导出值会为undefined，破坏模块求值链
