本文深入探讨了在异步操作中，特别是使用`promise.catch`进行错误捕获时可能遇到的陷阱，着重分析了`fetch` api的promise拒绝行为。针对常见的“too many requests”错误，文章强调了简单重试机制的局限性，并详细介绍了如何通过引入指数退避策略和优化promise链式调用，构建一个更加健壮和高效的异步重试函数，从而提升应用的稳定性和用户体验。
在JavaScript的异步编程中，Promise及其错误处理机制catch是核心组成部分。然而，开发者在使用Promise.catch时，尤其是在构建异步重试逻辑时，常常会遇到错误未能按预期捕获的问题。这通常源于对Promise拒绝行为的误解，以及对外部函数（如fetch）如何处理错误的认知不足。
Promise拒绝的机制与fetch的特殊性
当Promise.catch未能捕获错误，但控制台却显示错误信息时，最常见的原因是作为Promise源的函数并未真正“拒绝”其返回的Promise。一个Promise只有在遇到未捕获的异常或显式调用reject方法时，才会进入拒绝状态。
以fetch API为例，这是一个常见的陷阱。fetch函数在遇到网络错误（如断网、DNS解析失败）时会拒绝其Promise。然而，对于HTTP状态码表示的错误，例如404 Not Found、500 Internal Server Error，甚至是429 Too Many Requests，fetch的Promise并不会被拒绝。相反，它会成功解析（resolve），并将一个包含这些错误状态码的Response对象传递给then回调。这意味着，如果你没有在then回调中显式检查response.ok属性或response.status，并根据需要抛出错误或拒绝Promise，那么catch块将永远不会被触发。
示例：fetch的错误处理
// 错误的fetch错误处理方式 (catch不会捕获HTTP错误状态码)
fetch(url)
.then(response => {
// 即使response.status是404或500，这里也会执行
console.log('Fetch successful but status might be an error:', response.status);
return response.json();
})
.catch(error => {
// 只有网络错误才会进入这里
console.error('Network error:', error);
});
// 正确的fetch错误处理方式 (确保HTTP错误状态码也能被catch捕获)
fetch(url)
.then(response => {
if (!response.ok) {
// 如果HTTP状态码表示错误，则抛出错误，使Promise进入拒绝状态
throw new Error(`HTTP error! Status: ${response.status}`);
}
return response.json();
})
.catch(error => {
// 现在可以捕获网络错误和HTTP错误状态码
console.error('Operation failed:', error);
});简单重试机制的局限性与“雪崩效应”
在实现异步操作的重试逻辑时，一个常见的错误是采用简单的、快速连续的重试机制。例如，当一个请求因服务器过载或限流（429 Too Many Requests）而失败时，立即进行下一次重试，往往会导致以下问题：
- 加剧服务器压力： 快速连续的重试请求，尤其是在大量客户端同时进行时，会进一步增加服务器的负担，可能导致服务器从短暂故障演变为全面崩溃，形成“雪崩效应”（Avalanche Failure）。
- 触发更严格的限流： 服务器可能会识别出这种快速重试模式，并施加更严格的限流策略，甚至暂时封禁客户端IP，导致重试变得无效。
- 资源浪费： 客户端在无效的重试中浪费网络带宽和计算资源。
构建健壮的异步重试函数：引入指数退避策略
为了解决上述问题，生产级别的重试系统通常会引入“退避策略”（Backoff Strategy），其中最常见且有效的是“指数退避”（Exponential Backoff）。指数退避的核心思想是，在每次重试失败后，等待的时间逐渐增加，给服务器留出恢复或处理的时间，同时也避免了快速触发限流。
下面是一个结合了指数退避和Promise链式调用的健壮重试函数实现。
辅助函数：delay
首先，我们需要一个能够返回一个在指定时间后解析的Promise的delay函数。
/**
* 创建一个在指定毫秒数后解析的Promise。
* @param {number} t 延迟的毫秒数。
* @returns {Promise}
*/
function delay(t: number): Promise {
return new Promise(resolve => setTimeout(resolve, t));
} 退避时间计算函数：calcBackoff
接着，定义一个计算每次重试之间等待时间的函数。这里我们采用一个简单的线性增长模型，也可以根据需求设计更复杂的指数增长。
// 最小重试等待时间
const kMinRetryTime = 100; // 100毫秒
// 每次重试额外增加的时间
const kPerRetryAdditionalTime = 500; // 每次重试额外增加500毫秒
/**
* 计算基于重试次数的退避时间。
* @param {number} retries 当前的重试次数（从1开始）。
* @returns {number} 应该等待的毫秒数。
*/
function calcBackoff(retries: number): number {
// 确保最小等待时间，并根据重试次数线性增加
return Math.max(kMinRetryTime, (retries - 1) * kPerRetryAdditionalTime);
}核心重试函数：retry
最后，构建我们的retry函数。这个版本移除了外部的new Promise包装，而是通过Promise链式调用和递归来管理重试逻辑，使得代码更加简洁和符合Promise的惯用模式。
/**
* 带有指数退避策略的异步重试函数。
* @param {Function} fn 要执行的异步函数，它必须返回一个Promise。
* @param {any} params 传递给fn的参数。
* @param {number} [times=1e9 + 7] 最大重试次数。
* @returns {Promise} fn成功解析时的结果，或在所有重试失败后抛出的错误。
*/
export function retry(fn: Function, params: any, times: number = 1e9 + 7): Promise {
let retries = 0; // 记录当前的重试次数
/**
* 尝试执行fn并处理重试逻辑的内部函数。
* @returns {Promise}
*/
function attempt(): Promise {
return fn(params).catch((err: Error) => {
retries++; // 增加重试计数
console.warn(`Attempt failed (retry ${retries}/${times}):`, err.message); // 使用warn提示失败
if (retries <= times) {
// 如果还有重试次数，则计算退避时间并延迟后再次尝试
const backoffTime = calcBackoff(retries);
console.log(`Retrying in ${backoffTime}ms...`);
return delay(backoffTime).then(attempt);
} else {
// 如果所有重试都已用尽，则抛出原始错误
console.error(`All retry attempts failed after ${times} tries.`);
throw err;
}
});
}
return attempt(); // 启动第一次尝试
} 使用示例：
// 假设这是一个模拟的异步请求函数，有一定几率失败 async function mockFetchData(id: string): Promise{ const random = Math.random(); if (random < 0.7) { // 70%的几率失败 console.log(`Request for ${id} failed.`); // 模拟fetch的HTTP错误，需要手动抛出 throw new Error(`Failed to fetch data for ${id} (simulated HTTP 500)`); } console.log(`Request for ${id} succeeded.`); return `Data for ${id}`; } // 调用重试函数 (async () => { try { const result = await retry(mockFetchData, "user-123", 5); // 最多重试5次 console.log("Final successful result:", result); } catch (error) { console.error("Operation ultimately failed:", error.message); } })();
总结与注意事项
- 理解Promise拒绝： 确保你的异步函数在遇到错误时真正拒绝其Promise，而不是成功解析一个表示错误状态的对象。对于fetch，这意味着你需要在.then()中手动检查response.ok并抛出错误。
- 避免快速重试： 简单的、快速连续的重试机制可能适得其反，加剧服务器压力并触发更严格的限流。
- 采用退避策略： 引入指数退避或其他合理的退避策略，可以有效缓解服务器压力，提高重试成功的几率。
- 优化Promise链： 通过Promise链式调用和递归来构建重试逻辑，可以使代码更加简洁、易读，并避免不必要的new Promise包装。
- 错误日志： 在重试过程中打印有用的日志信息（如当前重试次数、预计下次重试时间），有助于调试和监控。
通过遵循这些最佳实践，我们可以构建出更加健壮和高效的异步重试机制，从而提升应用的稳定性和用户体验。
