嵌套try-catch本身不显著影响async执行效率，真正问题在于错误处理设计不当：将非异步逻辑塞入try块、catch中重复高开销操作、过深嵌套污染作用域；应采用分层职责分离、显式错误分类与轻量捕获策略。
嵌套 try-catch 本身不显著拖慢 async 逻辑的执行效率，但错误处理结构设计不当，会间接引发性能、可维护性和调试成本问题。
嵌套不是性能瓶颈，失控才是
JavaScript 引擎对 try-catch 的语法解析和正常流程下的运行开销极小。只要没有实际抛出异常，嵌套多层 try-catch 几乎不影响执行速度。真正影响效率的是以下行为：
- 把大量非异步、非易错逻辑（如状态更新、UI 渲染、条件判断）塞进 try 块，导致异常发生时回溯路径变长、堆栈更混乱
- 在 catch 中重复调用高开销操作（如多次重试未加退避、同步遍历大数组、未节流的日志上报）
- 嵌套过深导致变量作用域污染，迫使引擎保留更多闭包上下文，轻微增加内存压力
async/await 下嵌套的典型低效模式
常见但不推荐的写法，表面“安全”，实则掩盖问题：
- 整个业务链路（获取 token → 请求用户信息 → 处理权限 → 更新 UI）全包在一个 try 里：一旦某步失败，无法区分是网络超时、token 过期还是前端数据转换出错
- 每个 await 都单独套一层 try-catch，且每层都做完整错误提示+日志+状态还原：代码膨胀、重复逻辑多，维护成本高
- 在 finally 中 await 异步清理（如关闭连接、上报埋点）：阻塞后续流程，违背 finally “同步收尾”语义，还可能引发未捕获的 Promise rejection
高效替代方案：分层 + 显式 + 轻量
不靠嵌套，靠职责分离：
- 网络层（fetch 封装）：内部重试 + 统一错误分类（NetworkError / TimeoutError / HttpError），抛出带 code 和 meta 的业务错误
- 数据层（parse / transform）：单独 try-catch JSON.parse 或 schema 验证，失败即 throw ParseError，不混入网络逻辑
- 业务层（useEffect / handler）：只包裹真正需要用户感知或流程中断的 await，catch 后聚焦 UI 响应（toast / fallback UI），不重复处理底层已归类的错误
- 并发场景优先用 Promise.allSettled，避免为单个失败 Promise 拉垮整组请求，也省去层层 try-catch
要不要加？关键看三点
加 try-catch 不是为了“全覆盖”，而是为了：
- 是否需要阻止异常冒泡导致流程中断（比如轮询中某次失败不该停掉整个定时器）
- 是否需补充上下文（如记录当前请求 ID、用户操作路径，便于排查）
- 是否要触发差异化响应（401 跳登录，429 提示稍后再试，500 显示兜底页）
满足任一才值得加，且尽量控制在最小必要 await 表达式粒度。
