try-catch需将await置于try块内以捕获异步异常；应按业务语义分组包裹、区分错误类型并路由处理；finally用于确定性清理，递归与并发需各自独立保护。
try-catch 本身不“认识”异步，它只捕获当前同步执行上下文中的异常。要让它在异步场景中真正起作用，关键不是机械加块，而是让 await 表达式落在 try 块内，从而把异步流程“拉回”同步控制流中。语义化的核心，是让每个 try-catch 明确表达“这一段异步操作的意图和边界”。
按业务语义分组包裹 await
不要把多个不相关的异步调用塞进一个 try 块。比如获取用户、加载列表、拉取配置，三者失败原因和恢复策略不同，合并在一处会导致错误归因模糊、处理逻辑耦合。
- 获取用户失败 → 可能跳登录或展示访客态
- 列表加载失败 → 可重试或显示空状态
- 配置拉取失败 → 可降级使用默认值
更合理的写法是为每类操作单独包裹，或用 .catch() 链式兜底，保持职责清晰。
错误类型需可识别、可路由
catch 中不要只做 console.error 或统一弹窗。应通过 error 实例的属性（如 name、status、code）或自定义错误类（NetworkError、AuthError、ParseError）区分语义。
立即学习“Java免费学习笔记（深入）”；
- 遇到 TypeError 或 NetworkError：提示“网络异常，请稍后重试”
- 响应状态码为 401：触发 token 刷新或跳转登录页
- JSON 解析失败（SyntaxError）：记录日志并 fallback 到空数据
- 业务错误（如 { code: 1002 }）：按 code 映射具体提示文案
finally 用于确定性清理，而非异步等待
finally 是“无论如何都要执行”的收尾环节，适合清除定时器、取消 pending 请求、释放锁等确定性操作。若需 await 清理动作（如关闭连接），必须确保函数为 async，且清楚知道：finally 内 await 的异常会覆盖原错误。
- ✅ 推荐：clearTimeout(timer); removeEventListener(...)
- ⚠️ 谨慎：await api.logError(err) —— 应设超时或 fire-and-forget，避免阻塞主流程
递归与并发需独立保护上下文
异步递归（如轮询、重试）中，每次递归调用都构成新的异步执行上下文。只在外层 try 里调用一次，后续递归就脱离保护。
- ❌ 错误：外层 try 包 fetchWithRetry()，但递归体内部无 try
- ✅ 正确：每次递归前，自身函数体已由 try-catch 包裹
- 并发场景（如 Promise.all）建议用 allSettled + 单独判断，或为每个 Promise 配置独立 catch，避免一个失败导致整组中断
