嵌套 try-catch 的核心目的是实现错误隔离与策略分治，按网络层、解析层、业务逻辑层、副作用层分层捕获对应错误，配合块级作用域、promise.allsettled 和明确的边界动作（检查可执行性、错误分类、finally 不 await）避免失控。
嵌套 try-catch 不是为了堆深度，而是为了在高频异步流水线中实现“错误隔离”和“策略分治”——每个层级只关心自己该管的错，不干扰上下游。
按环节职责划分嵌套层级
高频流水线（如用户登录 → 拉取权限 → 加载首页数据 → 预加载推荐）中，各环节失败影响不同，应分层捕获：
- 网络层：捕获 fetch 失败、超时、连接中断，可重试或降级为缓存
- 解析层：单独包裹 JSON.parse 或 schema 校验，区分 SyntaxError（脏数据）与业务结构异常
- 业务逻辑层：检查响应 code、token 过期、权限不足等，触发跳转或弹窗
- 副作用层：UI 更新、状态写入前加 try，避免 setState 时组件已卸载
用块级作用域替代变量污染
避免在外层声明 let user、let posts 等变量，改用内层独立声明 + 显式传递：
- 每个 await 在自己的 try 块里执行，例如
const profile = await fetchProfile()在内层 try 中声明 - 需跨环节使用的字段（如 profile.id），只传 ID，不传整个响应对象
- 对并行子任务（如头像+昵称+积分），用
Promise.allSettled替代串行嵌套，天然支持各自 catch
嵌套中必须做的三件事
每一层嵌套不是孤立存在，要明确其边界动作：
-
检查是否仍可执行：React 用 ref 标记 mounted，Vue 用
isMounted，catch 中先判断再更新状态 -
错误分类后处理：用
err.name、err.status或自定义err.type区分，不依赖 message 字符串匹配 - finally 不做 await：清理 loading、关闭 modal 可以，但不要在里面调用异步日志上报；若必须上报，内部自行 try-catch
避免嵌套失控的实操习惯
金字塔结构往往源于重复逻辑未收敛，可用这些方式扁平化：
- 把通用错误处理（如统一上报、打点）抽成工具函数，嵌套内只写差异化恢复逻辑
- 用封装函数替代裸 try，比如
const [data, err] = await to(fetch(...))，后续用 if 分支判断 - 对强依赖但允许局部失败的链路（如主接口失败后自动 fallback 到备用接口），外层 try 包主请求，内层 try 包 fallback，不层层 deep await
