多层 await 嵌套不推荐，因其掩盖并发机会、放大错误传播、拖慢初始化；应改用依赖拓扑识别与有向执行控制，如 promise.all 显式声明依赖并并发执行。

多层 await 嵌套本身不是推荐做法，它容易掩盖并发机会、放大错误传播路径、拖慢初始化速度——真正需要的是「依赖拓扑识别 + 有向执行控制」。

为什么直接写多层 await 会出问题

比如写成 await initA(); await initB(); await initC(); 看似清晰，但若 initC 实际只依赖 initA 结果，而 initB 可并行执行，这种写法就人为串行化了本可并发的操作。更糟的是，一旦 initB 失败，initC 就完全没机会运行（哪怕它不依赖 initB）。

常见错误现象：
- 初始化耗时翻倍（本可 300ms 完成，串成 900ms）
- 错误堆栈难以定位（Uncaught (in promise) 指向最外层 await，而非真实失败函数）
- 后续模块因“未按预期顺序 resolve”而读到 undefined

用 Promise.all + 显式依赖声明替代嵌套 await

把初始化任务建模为节点，依赖关系建模为有向边，再用 Promise.all 控制并发边界。关键不是避免 await，而是让每个 await 都有意义。

• 先拆出原子初始化函数，每个返回自己的结果对象（如 { user, token }），不直接修改全局状态
• 用变量承接前置依赖结果，再传入后续函数：

  const user = await initUser();
  const [profile, permissions] = await Promise.all([
    initProfile(user.id),
    initPermissions(user.role)
  ]);

• 避免在 Promise.all 内部再套 await —— 这会退化为串行；所有待并发任务必须是已调用的 Promise，不是 await 表达式

处理循环依赖或动态依赖的兜底方案

当 A 依赖 B 的部分结果、B 又依赖 A 的配置项时，硬靠 await 层级无法解耦。此时应引入中间协调层：

• 用 Promise.resolve() 占位未就绪依赖，后续用 .then() 注册回调（类似事件总线）
• 对动态依赖（如根据 env 决定是否加载 analytics），提前构造 Promise 数组：const inits = [initCore(), env === 'prod' ? initAnalytics() : Promise.resolve()];
• 慎用 async/await 在循环中（如 for (const item of list) await init(item)）——这本质是串行，改用 map().map(Promise.resolve).all() 并发触发

真正难的不是写多少层 await，而是画清依赖图后，决定哪些该等、哪些该放、哪些该拆成 lazy 初始化。初始化逻辑越往后移（比如组件首次 render 时才加载非首屏数据），整体启动越快，但错误捕获和重试机制就得越细粒度——这点常被忽略。