try-catch仅捕获竞态引发的错误，不防止竞态；防竞态需协调共享状态访问，如用AbortController过滤过期响应、分层try-catch隔离失败、Promise.allSettled处理并发、finally只做同步清理。

在 async 函数中用 try-catch 本身不解决并发竞争，它只是错误捕获工具；真正防止竞态的关键是协调共享状态的访问时机。try-catch 的作用，是在竞态发生后（比如数据被覆盖、校验失败、请求过期）及时捕获异常并做兜底处理，而不是阻止竞态产生。

明确哪些操作会引发竞态

常见诱因包括：

• 多次快速触发同一异步操作（如双击提交、频繁刷新），导致多个 fetch 同时进行，后返回的数据覆盖先返回的结果
• 多个 await 操作读写同一个变量（如全局缓存、React state、Vuex store），且未加有效性校验
• 串行依赖链中，中间步骤结果被后续异步逻辑误读（例如：await getUser() → 立即更新 UI → 但此时 await getPosts() 还没完成，其他代码却已基于不完整数据执行）

用信号机制过滤过期响应

给每次请求绑定唯一标识，在响应到达时判断是否仍有效：

• 用 AbortController.signal 配合 fetch，请求取消后，其响应不再被接受
• 手动维护一个 requestId 或时间戳，在发起请求时记录，在 then/catch 中比对当前活跃 ID 是否匹配
• 示例：用户点击刷新，先 abort 当前 controller，再新建一个；收到响应时检查 signal.aborted === false 再更新状态

按业务单元分层 try-catch，避免连锁中断

不要把一连串异步调用全塞进一个 try 块。应按语义拆分，让失败局部化：

• 获取用户信息失败 → 返回默认对象，不影响后续帖子加载
• 加载帖子失败 → 显示空列表，但头像和昵称照常渲染
• 每个关键 await 单独加 .catch() 或包裹小 try-catch，而不是共用一个大块
• 这样即使某一步出错，其余流程仍可推进，减少“雪崩式失败”

并发控制优先用 Promise.allSettled 而非 all

当需要同时发起多个独立请求时：

• Promise.all：任一失败即整体 reject，无法拿到其余成功结果
• Promise.allSettled：始终 resolve，返回每个 Promise 的 status + value 或 reason，便于分别判断和恢复
• 配合 try-catch 可在每个 settled 结果里做细粒度处理：成功则更新对应字段，失败则打日志或设 loading 为 false

finally 中只做同步清理，不 await 异步操作

finally 块保证执行，但若在里面 await 异步操作，会导致函数实际返回延迟，破坏调用方对时序的预期：

• ✅ 正确：关闭 loading、重置 isSubmitting、清空临时缓存（都是同步赋值）
• ❌ 错误：await api.reportError()、await localStorage.setItem() —— 这些可能失败或卡住，且错误无法被外层 catch 捕获
• 如需异步清理，应在 finally 外单独发起，并用 .catch(() => {}) 静默处理