公司用的内部系统，点一下要转十秒；打卡、查资料全卡在加载上，员工急得直拍桌子。这背后八成是客户端请求处理瓶颈在作怪。
什么是客户端请求处理瓶颈？
简单说，就是用户操作（比如点击按钮、提交表单）发出的请求，服务器接不住或处理太慢，导致页面迟迟没反应。不是网速慢，也不是电脑卡，而是系统“堵”在了通信环节。
举个常见场景：月底报销高峰期，几十人同时上传发票，系统直接卡死。财务小李刷新五次才成功提交，隔壁老王干脆放弃改用纸质——这不是个别现象，而是典型的请求堆积。
瓶颈藏在哪？
很多人第一反应是“服务器不行”，但问题往往出在设计上。比如前端一次性发几十个HTTP请求去拉数据，后端没做并发控制，线程池瞬间耗尽。或者接口没加缓存，每次都要查数据库，CPU占用一路飙升。
另一个隐形杀手是长连接滥用。有些系统用WebSocket持续推送状态更新，但没限制频率，一个页面开着就不断发心跳包。上百人同时在线，光维持连接就把带宽占满。
代码层怎么优化？
前端可以合并请求。比如原本要调5次API拿不同数据，改成一次调用返回聚合结果：
// 优化前：多次请求
fetch('/api/user');
fetch('/api/orders');
fetch('/api/messages');
// 优化后：单次聚合
doFetch('/api/dashboard'); // 一口气回传全部后端则要设限流。比如用Redis记录每分钟请求次数，超了就返回429：
if (redis.incr('req:' + userId) > 100) {
return res.status(429).send('请求太频繁');
}日常排查建议
打开浏览器开发者工具，切到Network标签，点几个功能看看。如果看到一堆红条、TTFB（首字节时间）动辄几百毫秒，基本可以锁定问题。
再查服务器日志，看有没有大量超时或错误堆叠。有时候一个慢查询拖垮整个连接池，其他正常请求也被晾着。
别等全员抱怨才动手。平时留意响应变化，像监控体温一样盯住关键接口延迟，早发现早处理。