大厂前端高并发业务前端也要懂削峰和降级一、高并发不是后端一个人的事前端面对高并发时经常被误认为只是“多点用户访问页面”。但大促、直播、抢购、热点事件下前端行为会直接影响后端压力轮询频率、重复点击、接口并发、资源加载、错误重试都会放大流量。前端不懂削峰后端会被你打出鼓点。高并发业务里前端要参与容量设计。按钮怎么防重复接口怎么合并请求怎么取消失败怎么降级静态资源怎么缓存都是前端责任。二、流量链路用户动作到后端压力flowchart TD A[用户点击] -- B[前端防抖/节流] B -- C[请求合并与取消] C -- D[接口限频] D -- E[后端服务] E -- F[前端降级展示]重复点击是最常见的问题。用户紧张时会狂点网络慢时会再点按钮如果不锁后端就收到一串重复请求。别笑线上真就这么炸过。三、代码示例请求中的按钮状态function SubmitButton({ onSubmit }: { onSubmit: () Promisevoid }) { const [loading, setLoading] useState(false); async function handleClick() { if (loading) return; setLoading(true); try { await onSubmit(); } finally { setLoading(false); } } return button disabled{loading} onClick{handleClick}提交/button; }这个代码很普通但非常重要。前端工程里很多高并发保护都是这些朴素动作。按钮锁、请求取消、缓存、降级比炫酷动画更值钱。四、工程边界失败体验也要设计高并发时后端可能限流、排队、降级。前端不能只显示“系统错误”。要区分排队中、库存不足、请求过快、服务繁忙、网络失败。用户知道发生了什么就少刷新几次用户越慌系统压力越大。取舍方面实时刷新体验好但压力大延迟刷新压力小但用户可能焦虑。可以用服务端推送、短轮询退避、静态兜底页、局部刷新组合。前端要和后端一起设计流量节奏。还要做压测配合。前端脚本模拟用户点击、刷新、失败重试比单纯后端接口压测更接近真实流量。高并发不是后端独舞前端也要上台合拍。缓存策略要提前设计。静态资源使用 hash 文件名和长缓存接口数据根据业务设置短缓存或本地兜底。高并发时每一次不必要的资源请求都是浪费。前端缓存不是“浏览器会处理”而是需要明确策略。还要处理灰度和降级文案。核心功能不可用时用户看到的提示会影响行为。如果文案让用户不断刷新系统压力会更大如果提示排队和预计恢复用户会更平静。前端体验也是流量治理的一部分。最后前端要把关键埋点给后端容量团队点击率、重试率、取消率、错误展示次数。没有这些数据后端只能看到流量上涨却不知道用户行为为什么变了。边缘缓存和 CDN 也要配合。静态资源尽量走 CDN接口根据业务允许程度做边缘缓存或预取。高并发时离用户越近解决问题中心服务压力越小。前端团队不能只关心组件也要理解资源分发。还要做好版本兼容。大促期间用户可能打开旧页面、缓存旧 JS、接口已经升级。前端要处理接口字段缺失和灰度版本差异。高并发现场最怕“只有新版本能正常用”。五、总结大厂前端高并发业务里前端要负责防重复、请求合并、取消、缓存和降级展示。削峰不只在后端用户动作的第一道闸门就在前端。
