在实际开发中,前端常遇到 多接口并行请求 的场景:
用户痛点:若每个请求失败都弹出提示,用户会看到多次重复的 Toast,体验极差。
核心问题:如何让 批量请求中的多个错误,仅触发 一次全局提示?
业务背景:用户点击结算按钮后,前端并行请求5个接口:
const requests = [
checkStock(), // 库存检查
validateCoupon(),// 优惠券校验
checkAddress(), // 地址校验
calculateTax(), // 税费计算
getShippingFee() // 运费计算
];
问题复现:弱网环境下,5个接口同时失败,触发5次弹窗:
用户反馈:“页面疯狂弹窗,根本不知道发生了什么!”
技术目标:无论多少请求失败,只弹一次 Toast。
方案实现:
let hasError = false; // 全局状态标记
const handleCheckout = async () => {
try {
awaitPromise.all(requests.map(req =>
req.catch(() => {
if (!hasError) {
showToast("结算失败,请重试");
hasError = true; // 锁定状态
}
})
));
} finally {
hasError = false; // 重置状态
}
};
效果:首次失败触发弹窗,后续错误被静默处理。
遗留问题:
技术目标:区分错误类型,聚合提示信息。
class ErrorQueue {
constructor() {
this.queue = [];
this.timer = null;
}
push(error) {
this.queue.push(error);
if (!this.timer) {
this.timer = setTimeout(() => {
this.showAggregatedError();
this.clear();
}, 500); // 聚合500ms内的错误
}
}
showAggregatedError() {
const messages = [...new Set(this.queue.map(e => e.message))];
showToast(`结算失败:${messages.join(",")}`);
}
clear() {
this.queue = [];
this.timer = null;
}
}
const errorQueue = new ErrorQueue();
// 在请求拦截器中捕获错误类型
axios.interceptors.response.use(null, error => {
const errorType = error.response?.data?.code || "NETWORK_ERROR";
errorQueue.push({
type: errorType,
message: getErrorMessageByCode(errorType) // 根据错误码映射文案
});
return Promise.reject(error);
});
效果:
errorQueue
统计高频错误类型技术目标:对可恢复错误(如网络抖动)自动重试,减少用户感知。
const fetchWithRetry = async (url, retries = 2) => {
try {
const res = await fetch(url);
return res.json();
} catch (err) {
if (retries > 0 && isRetriableError(err)) { // 判断是否可重试
await sleep(1000); // 延迟1秒
return fetchWithRetry(url, retries - 1);
}
throw err; // 最终失败
}
};
// 在结算流程中替换原始请求
const requests = [
fetchWithRetry("/api/stock"),
fetchWithRetry("/api/coupon"),
// ...
];
技术收益:
技术目标:结合 Sentry 监控 + 服务端日志,实现立体化防护。
import * as Sentry from "@sentry/browser";
// 在错误队列中上报聚合错误
errorQueue.showAggregatedError = () => {
const messages = this.queue.map(e => e.type);
Sentry.captureMessage(`Checkout Errors: ${messages.join(",")}`);
// ...原有弹窗逻辑
};
即使前端提示成功,服务端再次校验订单状态,避免前端状态不一致。
黄金公式:STAR+
基础层:全局标志位拦截 → 体验层:错误队列聚合 →
容错层:请求重试策略 → 监控层:Sentry埋点
技术分层法
将方案拆分为 基础实现 → 体验优化 → 生产保障 三层递进,展示技术思考的完整性:
第一层:Promise.allSettled集中处理(快速止血)
第二层:错误类型分级(核心功能优先提示)
第三层:Sentry监控+服务端兜底校验(系统高可用)
原理溯源
细节降维
用具体代码片段佐证技术判断:
// 展示关键代码设计(如错误去重逻辑)
const errorCache = new Map();
axios.interceptors.response.use(null, error => {
const key = error.config.url + error.status;
if (!errorCache.has(key)) {
showToast(error.message);
errorCache.set(key, Date.now());
}
});
量化思维
用数据证明方案价值:
"弹窗频率从3次/秒降为0.1次/秒,错误日志上报量减少85%"
关联技术趋势
"虽然当前使用标志位控制,但WebSocket重连机制在新项目中已落地"
暴露技术权衡
"放弃第三方toast库的自动去重功能,选择自研方案以保持轻量(包体积减少30KB)"
预判延伸问题
提前准备关联问题应答:
忌空谈概念
❌ 错误示范:"用防抖函数控制弹窗频率"
✅ 正确姿势:"设置300ms防抖阈值,通过performance.now()记录最后一次错误时间戳"
忌过度甩锅
❌ 危险发言:"后端接口不稳定导致频繁报错"
✅ 高情商表达:"通过协商制定重试策略+服务降级方案,建立前后端错误处理SOP"
忌虎头蛇尾
收尾时增加 经验沉淀:
"输出《前端错误处理规范》,推动团队建立统一拦截器,减少重复开发量"
面试官:前端批量请求失败 Toast 重复弹窗怎么解决?回答框架:
1. 定位场景:电商结算页5接口并发 → 用户被重复弹窗淹没
2. 分层方案:
- 基础层:Promise.allSettled集中捕获
- 体验层:构建错误队列聚合分类
- 监控层:Sentry埋点+服务端二次校验
3. 技术细节:基于Map实现错误去重(代码片段)
4. 成果数据:弹窗减少98%,客诉率下降40%
5. 经验延伸:输出团队规范,复用到3个核心模块
有会员购买、辅导咨询的小伙伴,可以通过下面的二维码,联系我们的小助手。