嵌套 try-catch 在 async 中应按责任边界隔离错误处理，每层对应语义清晰的不可拆分单元；需满足内层 catch 明确异常去向、finally 禁止抛异常两大约束，否则易失效。
嵌套 try-catch 在 async 复杂业务逻辑中不是“多加几层更保险”，而是为不同责任边界的错误提供独立处理能力。关键不在嵌套本身，而在每层是否对应一个语义清晰、不可拆分的错误处理单元。
何时需要嵌套：按错误策略隔离
当一段 async 流程里，不同步骤失败后需执行**完全不同的兜底行为**，且这些行为不能合并或委托给外层统一处理时，才考虑嵌套。例如：
- 调用支付接口 → 成功则发通知；失败则回滚库存 → 但回滚库存本身也可能失败，且这个失败绝不能掩盖原支付错误
- 读取配置文件 → 解析 JSON → 校验字段结构；JSON 解析失败要降级到默认配置，而字段校验失败必须阻断流程并提示用户
- 上传图片 → 生成缩略图 → 同步到 CDN；前两步失败可重试，CDN 同步失败只需记录告警，不影响主流程返回
嵌套写法的两个硬约束
嵌套能起作用的前提是严格遵守两条规则：
- 内层 catch 必须明确决定异常去向：不处理就 throw e 向上传播；处理完若还需上层干预，必须显式 re-throw 原异常（不能只写 throw，否则堆栈丢失）
- finally 块禁止抛出任何异常：哪怕只是 fs.closeSync() 或 localStorage.removeItem() 这类看似安全的操作，也必须包一层内部 try-catch 并仅记录、不 throw —— 否则原始错误将被静默覆盖
替代嵌套的更优方案
多数所谓“复杂逻辑”其实不需要嵌套，用以下方式更清晰：
- 单层 try + 类型判断：对 fetch、JSON.parse、业务校验等不同来源的错误，用 instanceof 或 error.name 区分，在同一个 catch 里走不同分支
- 拆分为独立 async 函数：把“获取数据”“转换格式”“提交结果”各自封装，每个函数内部用 try-catch 自洽处理，调用方只关注组合逻辑
- 自定义错误类 + 错误拦截器：统一捕获后，根据 error.code 路由到日志、告警、UI 提示或降级策略，避免重复写 catch 块
async 中嵌套失效的典型陷阱
以下写法看似嵌套，实际 catch 完全无效：
-
try { fetch('/api').then(data => doSomething(data)); } catch(e) { }—— fetch 返回 Promise 立即结束，then 是异步回调，不在 try 执行上下文中 -
async function fn() { try { setTimeout(() => { throw new Error(); }, 0); } catch(e) { } }—— setTimeout 回调是新执行栈，与外层 try 无关 - await 后漏掉 try-catch，却指望外层函数的 try 捕获：await 必须出现在 try 块内，否则拒绝的 Promise 会直接冒泡
