前端高并发要防什么：请求合并、离线缓存与兜底页面
促销、抢购和突发热点会同时放大静态资源、接口请求和页面更新压力。SSR、CDN 与 WebSocket 解决的问题不同，不能作为一套“高并发模板”一起堆上去。先确认流量来自重复点击、资源回源还是实时推送，再决定前端该减什么、缓存什么、降级什么。
graph TD
A[海量用户突发点击/刷新] –> B[防线一: 客户端限流与请求合并/防抖]
B –> C[防线二: Service Worker 本地高频数据缓存与降级]
C –> D[防线三: 静态 CDN/Edge 托管]
D –> E[后端 API 网关]
前端侧负责减请求和保体验
前端代码运行在浏览器或 App WebView 中。前端侧治理主要是减少重复请求、提供降级体验，并把可缓存内容尽早交给 CDN；后端的限流、排队和数据保护仍不可缺少。
常见的认知误区与适用边界包括：
下述 TypeScript 代码演示了如何在前端客户端实现一个带有指数退避（Exponential Backoff）与熔断机制的高并发请求库：
interface RequestConfig {
maxRetries: number;
initialDelayMs: number;
timeoutMs: number;
}
class ResilientHttpClient {
private config: RequestConfig;
constructor(config: RequestConfig) {
selfConfigCheck(config);
this.config = config;
}
async fetchWithBackoff(url: string): Promise<any> {
let attempt = 0;
let delay = this.config.initialDelayMs;
while (attempt < this.config.maxRetries) {
try {
const controller = new AbortController();
const timeoutId = setTimeout(() => controller.abort(), this.config.timeoutMs);
const response = await fetch(url, { signal: controller.signal });
clearTimeout(timeoutId);
if (response.status === 429 || response.status >= 500) {
throw new Error(`服务器限流或异常: HTTP ${response.status}`);
}
if (!response.ok) {
throw new Error(`请求失败: Status ${response.status}`);
}
return await response.json();
} catch (err: any) {
attempt++;
if (attempt >= this.config.maxRetries) {
// 降级兜底方案：返回本地缓存或默认数据
console.warn(`请求连续失败 ${attempt} 次，触发客户端本地降级兜底`);
return this.getFallbackData();
}
// 加入随机抖动 (Jitter)，避免万级客户端同时重试打爆后端
const jitter = Math.random() * 200;
await new Promise((res) => setTimeout(res, delay + jitter));
delay *= 2; // 指数退避
}
}
}
private getFallbackData() {
return { isFallback: true, data: { status: "processing", message: "排队中，请稍后刷新" } };
}
}
function selfConfigCheck(config: RequestConfig) {
if (config.maxRetries <= 0 || config.timeoutMs <= 0) {
throw new Error("非法配置参数");
}
}
// 示例运行
const client = new ResilientHttpClient({ maxRetries: 3, initialDelayMs: 500, timeoutMs: 2000 });
client.fetchWithBackoff("/api/v1/seckill/status").then(console.log);
对于打到前端静态资源与接口的流量，工程师可在终端使用 curl 命令查验 CDN 缓存响应头与传输延迟：
curl -I -H "Accept-Encoding: gzip" https://static.example.com/sec-kill/index.js
在测试中需重点关注 Cache-Control 和 X-Cache 响应头是否成功命中 Edge 节点。
请求合并、离线缓存与静态兜底
在高并发前端应用中，推荐建立以下三大防护机制：
1. 客户端请求合并与防抖（Debounce & Batching）
用户在抢购或提交按钮上的连续点击，应当在前端进行拦截。除了将 button.disabled 设为 true 之外，需要全局拦截并废弃带有相同 Request Token 的重复 HTTP 请求。
2. Service Worker 离线缓存与本地降级
利用 Service Worker 拦截全局 fetch 事件。当检测到后端 API 返回 503 或网络超时时，立即从 IndexedDB 或 CacheStorage 中读取离线兜底模版呈现给用户，保持页面 UI 稳定。
3. API 响应数据瘦身
高并发场景下的接口 JSON 响应应当精简字段层级，避免冗余键值。压缩后的 JSON 能够缩短网络传输耗时并降低前端解析占用的主线程 CPU 时间。
测试人员可使用压测工具模拟并发请求下的接口表现；ab 适合简单 HTTP/1.1 场景，复杂协议可选择更贴近生产的工具：
ab -n 5000 -c 200 https://api.example.com/v1/goods/detail?id=1001
主要观察 P99 响应延迟指标以及 502/503 错误的占比变化。
轮询和推送都要有退出与背压
工程中常见的问题是在主页面滥用全局 setInterval 高频轮询。组件销毁或页面进入后台后未清理定时器，会持续发请求并增加 CPU、网络和内存开销；是否出现卡顿取决于请求处理和设备性能。
另一个典型反例是在实时大屏或高频交易列表场景中，直接将后端推送的并发 WebSocket 原始消息无节制地 push 进响应式状态数组中。由于触发了 DOM 节点的高频重新渲染，容易导致页面帧率（FPS）降至极低水平。
可在 Worker 中处理计算和聚合，并使用节流、批处理与 requestAnimationFrame 控制渲染频率。更新频率应按设备性能和交互需求设定，不必固定为 60FPS。
前端侧能做的是减少无效流量、尽早缓存和提供可用的降级体验。架构选择应从业务实时性、设备能力和后端承载能力出发，并用真实流量数据持续验证。
