try-catch 无法自动重试，因其仅捕获同步错误或已 await 的 promise 拒绝；重试需开发者显式实现“执行→判错→延迟→循环”闭环，并注意作用域、await 缺失、递归保护及调用层兜底。
try-catch 本身不处理异步重试，它只捕获同步错误或 被 await 的 Promise 拒绝时抛出的异常。所谓“失效”，本质是异步流程脱离了 try 块的作用域，或未正确 await 导致错误未被触发捕获。真正的重试必须由开发者主动控制执行时机、次数和终止条件。
为什么直接套 try-catch 无法自动重试
常见误区是以为写个 try-catch 就能“让失败的操作自动再跑一遍”。但 JavaScript 中：
- catch 块只是错误处理入口，不会自动重新执行 try 块里的代码
- 如果 await 被漏写（比如写了
fetch(url)没加 await），得到的是一个 pending Promise，不会 reject，也就不会进 catch - 在事件回调、定时器、Promise.then 中使用 try-catch，作用域仅限当次执行，后续异步调用（如递归、重试调用）不在保护范围内
重试必须显式编码，核心是“执行 → 判错 → 延迟 → 循环”闭环
可靠做法是封装一个 retry 函数，把重试逻辑收口，而不是每个地方手写 while 或 setTimeout：
- 用
for循环控制最大重试次数，配合await实现顺序等待 - 每次失败后，用
await new Promise(r => setTimeout(r, delay))控制延迟，避免阻塞主线程 - 通过
shouldRetry(error)判断是否值得重试：比如只对TypeError（网络中断）、503、504重试，跳过400、401等业务错误 - 成功立即 return；耗尽次数后 throw 最后一次错误，并附带重试统计（如
"failed after 3 attempts"）
异步递归场景要每层独立包裹
例如轮询或 token 刷新类逻辑，若只在外层 try 一次，后续递归调用就失去保护：
- 正确方式：每次递归调用前，确保它处于新的 try-catch 内部（如
return fetchWithRetry(url, retries - 1)写在 catch 里） - 避免在 catch 中直接调用函数却不 await，否则返回的是 Promise，错误仍可能未被捕获
- 涉及临时资源（如计时器、锁），建议每层加
finally清理，防止内存泄漏
调用层仍需兜底，不能只依赖内部重试
retry 函数内部再健壮，调用它的 async 函数本身仍是 Promise：
- 如果上层没处理这个 Promise 的 rejection（比如没写
.catch()或没用 try-catch 包裹调用），会触发unhandledrejection - 尤其在事件监听、Vue/React 生命周期钩子中，必须确保最终有错误出口：记录日志、展示提示、降级渲染等
- 多个无关异步操作不要共用一个 try-catch，否则前一个失败会导致后续全部跳过；可分别用
.catch()提供默认值，再统一处理
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
