异步异常处理分Promise链和async函数两类：Promise靠.catch()向后冒泡捕获，async需await配合try/catch同步拦截；混用时未await的Promise错误不进try/catch，推荐统一风格避免责任不清。
异步函数中的异常传播机制，关键在于“错误发生在哪里”和“谁来负责捕获”。Promise 链靠 .catch() 向后冒泡捕获，而 async 函数内部靠 await + try/catch 同步式拦截——两者底层都基于 Promise 状态，但捕获时机、作用域和写法逻辑完全不同。
Promise 链的错误冒泡机制
Promise 的拒绝（rejection）会沿链自动向后传递，直到遇到第一个 .catch() 或 .then(null, onRejected)。中间任何 .then() 抛出同步错误，也会转为 rejected 状态继续冒泡。
- 不依赖
await，只要在链中，.catch()就能捕获前面所有步骤的失败 - 未加
.catch()的 rejected Promise 会触发unhandledrejection事件，可能报错或静默失败 - 适合统一兜底处理：比如整个数据加载流程，最后用一个
.catch()统一展示错误提示
async 函数内必须 await 才能被 try/catch 捕获
try/catch 在 async 函数里只对 await 表达式生效。它把 Promise 的 rejection 转换为可同步捕获的异常；没 await，就只是创建了一个未处理的 Promise 对象，try/catch 完全感知不到。
- 写法更接近同步逻辑，适合分步控制：比如先校验 token，再请求用户数据，每步独立处理错误
- 如果漏写
await，错误不会进catch，而是变成未捕获拒绝，容易埋坑 - 多个
await可共用一个try/catch，也可拆成多个块实现细粒度处理
混用场景下的常见误区
实际项目中常混合使用 Promise 链和 async/await，这时异常流向容易混淆。
- 在
async函数里调用 Promise 方法但不await，错误仍走 Promise 链路径，不会进try/catch -
.then().catch()和try/catch套在一起时，外层try/catch捕不到内层链的未捕获拒绝 - 推荐原则：要么整条链用
.then/.catch，要么在async中统一await+try/catch，避免交叉责任不清
什么时候选哪种？
没有绝对优劣，看协作上下文和错误处理粒度需求：
- 需要逐环节定制错误响应（如登录失败跳转、网络失败重试、解析失败降级），优先
async/await + try/catch - 只需最终结果成功与否，且流程固定（如初始化加载多资源），用
Promise.all().catch()更简洁 - 库函数返回 Promise 但你不控制调用方式时，加
.catch()是最稳妥的兜底手段
