try-catch 无法有效处理并发异常，因其仅捕获 await 的 Promise 拒绝，而 Promise.all 会全盘失败且不提供各子任务状态；真正有效的策略是用 Promise.allSettled、单独 await + 最小粒度 try-catch 或 to() 工具函数实现显式容错。
try-catch 本身不直接处理并发异常，它只响应被 await 的 Promise 拒绝。在并发场景（如 Promise.all、多个并行 await）中，错误行为和恢复逻辑远比单个 try-catch 块能覆盖的更复杂——关键不在“能不能写”，而在“写了是否真起作用”。
Promise.all 会中断全部，但 try-catch 捕不到局部失败
当你用 await Promise.all([p1, p2, p3])，只要其中任意一个 Promise 被 reject，整个 all 就立刻 reject，其余成功任务的结果完全丢失。此时 try-catch 确实能捕获这个整体失败，但它无法告诉你：到底是哪一个失败了？其他两个有没有成功？要不要重试或降级？
- Promise.all 是“全有或全无”，不是“局部容错”
- try-catch 只拿到一个错误，无法解构出各子任务状态
- 业务上常需要“用户资料加载失败，但头像和配置仍可用”，all 不支持这种弱依赖
并发任务不能靠一个大 try 块统一兜底
把多个 await 全塞进同一个 try 块里，看似“安全”，实则掩盖问题：
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 前一个 await 失败后，后续 await 完全跳过，导致本可独立执行的任务被连带阻断
- 无法区分错误来源：是网络超时？token 过期？还是后端返回了非法 JSON？
- catch 中难以做差异化响应——401 应跳登录，500 应显示兜底页，但你只拿到一个泛化 Error 对象
未 await 的 Promise 拒绝，try-catch 完全无效
这是最常被忽略的失效点：只要没加 await，Promise 的 reject 就不会触发 catch。
立即学习“Java免费学习笔记（深入）”；
-
fetch('/api').then(...)放在 try 块里，但没 await → 错误静默，可能触发 unhandledrejection - fire-and-forget 类操作（如日志上报、埋点）必须在内部自行 catch，外层 try-catch 不可达
- 事件监听器中启动的 async 操作（如 click 后 fetch），若组件已卸载，Promise reject 也逃逸出 try 块作用域
真正有效的并发错误隔离策略
与其强行用 try-catch “包住一切”，不如用 Promise 原语 + 显式状态控制来设计容错：
- 用
Promise.allSettled替代Promise.all：返回每个任务的 { status, value/reason }，天然支持逐项判断 - 对需差异化恢复的任务，单独 await + 最小粒度 try-catch：比如用户主数据失败 fallback 缓存，头像失败则静默忽略
- 封装
to()工具函数，把错误转为返回值：const [err, data] = await to(fetch(...))，避免语法块膨胀 - 全局监听
unhandledrejection作为兜底，但不替代业务层的明确错误分支
