前端高并发要防什么请求合并、离线缓存与兜底页面促销、抢购和突发热点会同时放大静态资源、接口请求和页面更新压力。SSR、CDN 与 WebSocket 解决的问题不同不能作为一套“高并发模板”一起堆上去。先确认流量来自重复点击、资源回源还是实时推送再决定前端该减什么、缓存什么、降级什么。graph TD A[海量用户突发点击/刷新] -- B[防线一: 客户端限流与请求合并/防抖] B -- C[防线二: Service Worker 本地高频数据缓存与降级] C -- D[防线三: 静态 CDN/Edge 托管] D -- E[后端 API 网关]前端侧负责减请求和保体验前端代码运行在浏览器或 App WebView 中。前端侧治理主要是减少重复请求、提供降级体验并把可缓存内容尽早交给 CDN后端的限流、排队和数据保护仍不可缺少。常见的认知误区与适用边界包括轮询与事件推送高频轮询会放大后端负载WebSocket 则需要处理连接容量、断线恢复和消息背压。SSE、WebSocket 或带退避的轮询应根据单向/双向通信、在线量和实时性选择。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): Promiseany { 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?id1001主要观察 P99 响应延迟指标以及 502/503 错误的占比变化。轮询和推送都要有退出与背压工程中常见的问题是在主页面滥用全局setInterval高频轮询。组件销毁或页面进入后台后未清理定时器会持续发请求并增加 CPU、网络和内存开销是否出现卡顿取决于请求处理和设备性能。另一个典型反例是在实时大屏或高频交易列表场景中直接将后端推送的并发 WebSocket 原始消息无节制地push进响应式状态数组中。由于触发了 DOM 节点的高频重新渲染容易导致页面帧率FPS降至极低水平。可在 Worker 中处理计算和聚合并使用节流、批处理与requestAnimationFrame控制渲染频率。更新频率应按设备性能和交互需求设定不必固定为 60FPS。前端侧能做的是减少无效流量、尽早缓存和提供可用的降级体验。架构选择应从业务实时性、设备能力和后端承载能力出发并用真实流量数据持续验证。