Chrome Network面板中请求长期显示Pending，说明浏览器已发出请求但尚未收到服务器首个响应字节，问题需分段定位DNS、连接、TLS、排队或服务端处理等具体瓶颈，而非简单刷新。
Chrome Network面板中请求长期显示Pending，说明浏览器已发出请求但尚未收到服务器首个响应字节——这并非页面卡死，而是请求在DNS、连接、握手或服务端处理环节被阻塞，必须逐段定位瓶颈才能针对性解决。
确认Pending是否真实存在
先排除误判：点击该Pending请求→切换到Timing标签页→查看“Stalled”和“Blocking”两段耗时是否非零。若两者均为0，而“Request Sent”或“Waiting for…（TTFB）”持续增长，则问题确实在服务端响应延迟；若“Stalled”或“Blocking”明显拉长，才需聚焦网络链路。
【关键前提】Pending状态本身不可优化，只能优化其背后的具体阶段——盲目刷新或重试毫无意义。
快速定位阻塞环节
第一步：在Network面板顶部节流下拉框旁，点击“Network conditions”图标（齿轮状）→勾选“Disable cache”和“Preserve log”→刷新页面。
第二步：右键点击任意Pending请求→选择“Copy → Copy as cURL”→将命令粘贴至终端执行。若cURL能秒回结果，说明问题100%出在浏览器上下文（如CORS、扩展、并发限制）；若同样卡住，则是网络或服务端问题。
第三步：在Filter输入框中输入is:running，可立即筛选出所有当前处于Pending状态的活跃请求，避免被已完成请求干扰视线。
分段排查与修复
方法一：解决DNS与连接层阻塞
若Timing中“DNS Lookup”或“Initial Connection”耗时超300ms，大概率是本地DNS解析慢或TLS握手异常。此时在地址栏输入chrome://net-internals/#dns→点击“Clear host cache”；再访问chrome://net-internals/#sockets→点“Close idle sockets”。这两步能强制刷新底层网络状态，比重启浏览器更快生效。
方法二：绕过HTTP/1.1并发限制
Chrome对同一域名默认只允许6个HTTP/1.1并发连接，第7个请求会直接进入Queueing状态并显示为Pending。打开Network→点击任意Pending请求→看Headers里的“Initiator”列：若多个请求Initiator同为一个JS文件，且域名一致，就极可能是排队所致。此时可将部分接口拆分到子域名（如api1.example.com / api2.example.com），或推动后端启用HTTP/2——后者能复用单连接并发多路请求，彻底消除排队。
方法三：揪出CORS预检拦截
若Pending请求的Method显示为OPTIONS而非你代码里写的POST/PUT，且Preview为空白，说明fetch/fetch API触发了跨域预检，但服务器未正确响应。此时不要改前端，立刻检查服务端是否返回Access-Control-Allow-Origin、Access-Control-Allow-Headers等头信息。【注意】OPTIONS请求失败时，主请求永远不会发出，Network里只留一个灰掉的OPTIONS行——它卡在Pending，就是罪魁祸首。
