在 async 函数中实现错误隔离的核心是精准控制 try/catch 范围、合理使用 Promise.allSettled、封装带 fallback 的工具函数，并确保错误被感知和响应，而非忽略。

在 async 函数中实现错误隔离，核心是避免一个 Promise 失败导致整个函数流程中断或错误蔓延，关键在于精准控制 try/catch 范围、合理使用 Promise.allSettled、以及对单个异步操作做独立兜底。

用局部 try/catch 包裹独立异步操作

不要把所有 await 写在同一个 try 块里——那样一个失败就跳过后续逻辑。应为每个可能出错的异步调用单独加 try/catch，让它们互不影响：

• 每个 await 前后都可独立捕获错误，不影响其他分支执行
• 适合处理并行但非强依赖的任务，比如同时调用用户信息、配置、日志上报等接口
• 示例：获取用户数据失败时，仍可继续加载默认主题和本地缓存

用 Promise.allSettled 替代 Promise.all 处理批量请求

Promise.all 遇到任意一个 reject 就整体失败；而 Promise.allSettled 总会等待全部完成，返回每个 Promise 的 { status, value | reason }，便于逐个判断和恢复：

• 适用于“多个请求都要发，但彼此不耦合”的场景，如初始化阶段拉取多个微服务配置
• 遍历结果数组，只对 fulfilled 的做后续处理，对 rejected 的记录日志或降级使用默认值
• 注意它不阻止异常抛出，只是不让异常中断执行流

为关键异步调用封装带 fallback 的工具函数

把常用异步操作（如 fetch、数据库查询）封装成自带重试、超时、兜底返回的函数，从源头隔离不确定性：

• 例如 safeFetch(url, { timeout: 5000, fallback: {} })，内部自动 catch 并返回默认值
• 避免业务层重复写 try/catch，也防止忘记处理某些边缘异常（如网络中断、CORS、JSON 解析失败）
• fallback 值类型需与正常返回一致，保证调用方无需额外类型守卫

避免在顶层 async 函数中吞掉所有错误

隔离 ≠ 忽略。错误仍需被感知和响应：

• 局部 catch 后，该上报的错误要发监控（如 Sentry.captureException），该提示用户的要触发 UI 反馈
• 不要写空 catch 或只 console.log —— 这会让问题静默丢失
• 若某操作失败不影响主流程，可标记状态（如 hasUserData = false），后续逻辑据此分支处理