处理 async/await 嵌套 promise 错误的关键是避免隐式错误丢失、统一捕获层级、明确控制流走向：需用 try/catch 包裹每个 await，禁用链式 .then/.catch，扁平化嵌套，并合理使用 promise.reject() 替代 throw。
处理 async/await 中嵌套 Promise 的错误，关键在于避免隐式错误丢失、统一捕获层级、明确控制流走向。嵌套 Promise 本身不是问题，问题常出在 catch 没覆盖、await 位置不当、或多个异步操作混用 then 和 await 导致错误路径断裂。
用 try/catch 包裹每个 await 调用
async 函数内部的 await 表达式一旦抛错，会立即跳出当前执行，但只被最近的 try/catch 捕获。如果嵌套多层 Promise（比如 await fetch().then(...).catch(...)），错误可能被内层 catch 吞掉，外层无法感知。
- 避免在
await后链式调用.then()或.catch()，改用纯 await + try/catch - 对每个可能失败的异步操作单独包裹，尤其是嵌套调用（如先取 token，再用 token 请求数据）
- 示例：不要写
await api.getToken().then(t => api.getData(t))；而是写：const token = await api.getToken();<br> const data = await api.getData(token);
这样任一环节出错都会自然冒泡到外层 try/catch
统一错误处理边界，避免“吞错”
常见陷阱是内层 Promise 自己 .catch() 返回默认值（如 return []），导致外层逻辑误以为成功。这会让错误静默，调试困难。
- 除非业务明确需要降级（如缓存 fallback），否则不要在 Promise 链中提前
catch - 若必须降级，建议在最外层统一处理，并记录日志说明“已降级”，而不是让错误消失
- 可封装一个带日志和重试的
safeAwait工具函数，但需确保它仍能抛出错误供上层决策，而非隐藏
扁平化嵌套，减少深层 await 依赖
深层嵌套（如 await A → await B(A) → await C(B)）不仅增加错误传播路径，还降低可读性和测试性。优先考虑并行或分层解耦。
- 能并行的尽量并行：比如 token 和用户配置无关，就用
Promise.all([getToken(), getConfig()])同时发起 - 把嵌套逻辑拆成独立 async 函数，每个函数负责单一职责和自己的错误处理
- 用早期返回代替深层缩进：获取失败直接
throw或return，不继续向下 await
使用 rejected promise 替代 throw，便于组合
有时你需要在某个条件不满足时“让 await 失败”，但又不想用 throw（比如想区分业务错误和系统错误）。可以用 Promise.reject() 显式构造失败态。
- 例如：
if (!user) return Promise.reject(new Error('User not found')); - 这样调用方仍可用
await接收，且能被同一套 try/catch 捕获 - 比手动 throw 更易配合工具函数（如
Promise.allSettled场景下更可控）
