前端高并发要防什么：请求合并、离线缓存与兜底页面

促销、抢购和突发热点会同时放大静态资源、接口请求和页面更新压力。SSR、CDN 与 WebSocket 解决的问题不同，不能作为一套“高并发模板”一起堆上去。先确认流量来自重复点击、资源回源还是实时推送，再决定前端该减什么、缓存什么、降级什么。

graph TD A[海量用户突发点击/刷新] --> B[防线一: 客户端限流与请求合并/防抖] B --> C[防线二: Service Worker 本地高频数据缓存与降级] C --> D[防线三: 静态 CDN/Edge 托管] D --> E[后端 API 网关]

前端侧负责减请求和保体验

前端代码运行在浏览器或 App WebView 中。前端侧治理主要是减少重复请求、提供降级体验，并把可缓存内容尽早交给 CDN；后端的限流、排队和数据保护仍不可缺少。

常见的认知误区与适用边界包括：

1. 轮询与事件推送：高频轮询会放大后端负载；WebSocket 则需要处理连接容量、断线恢复和消息背压。SSE、WebSocket 或带退避的轮询，应根据单向/双向通信、在线量和实时性选择。
2. SSR 与静态化：SSR 会占用服务端渲染资源，但也能改善首屏与 SEO。对可预生成的活动页可优先 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。

前端侧能做的是减少无效流量、尽早缓存和提供可用的降级体验。架构选择应从业务实时性、设备能力和后端承载能力出发，并用真实流量数据持续验证。