异步递归中try-catch必须每层独立包裹，否则后续递归调用脱离保护范围导致异常漏捕、重试中断或无限错误循环；正确做法是每次递归前确保其异步上下文被try-catch覆盖，并在finally中清理资源。
在异步递归任务中，try-catch 不是简单“包一层”就能起作用的，它必须和异步流程的控制节奏对齐，否则会漏捕异常、中断重试逻辑，甚至导致无限错误循环。
为什么异步递归容易漏掉错误
异步递归的典型结构是：函数内部发起一个异步操作（如 fetch 或 setTimeout），成功后调用自身；失败时可能需要重试或终止。问题在于：
- 如果只在最外层
try包住首次调用，后续递归调用不在该try作用域内，抛错就直接冒泡到全局 -
await后的递归调用若没被catch捕获，错误不会自动传递给上一级catch - 未处理的 Promise rejection 会触发
unhandledrejection，但无法阻止当前递归链中断
正确包裹方式：每层递归都独立 try-catch
关键原则是：**每次递归调用前，确保其所在的异步执行上下文已被保护**。常见写法：
```js
async function fetchWithRetry(url, retries = 3) {
try {
const res = await fetch(url);
if (!res.ok) throw new Error(`HTTP ${res.status}`);
return await res.json();
} catch (err) {
if (retries console.warn(`重试中...剩余 ${retries} 次`, err);
await new Promise(r => setTimeout(r, 1000));
return fetchWithRetry(url, retries - 1); // 递归调用仍在 try-catch 内部
}
}
避免常见陷阱
- 不要把
await fetchWithRetry(...)放在外部try里再递归——那只是保护了第一次调用 - 不要在
catch中直接写fetchWithRetry(...)却不await它，否则递归返回的是 Promise，错误仍可能未被捕获 - 如果递归依赖状态（如 token 刷新），需确保错误处理中能更新上下文，否则重试会重复失败
配合 finally 做清理更稳妥
若递归中涉及临时资源（如锁、计时器、事件监听器），可在每层 try-catch 后加 finally 统一释放：
```js
async function pollUntilReady(id) {
let timer;
try {
const res = await api.checkStatus(id);
if (res.status !== 'ready') {
timer = setTimeout(() => {}, 2000);
return pollUntilReady(id);
}
return res;
} catch (err) {
throw new PollError(`轮询失败: ${err.message}`, id);
} finally {
if (timer) clearTimeout(timer);
}
}
