Google Chrome中fetch()背压机制失效问题排查求助

嘿，我之前也碰到过类似的情况，Chrome的这个缓存行为确实容易让人困惑！先给你理清楚问题根源，再说说怎么调整代码和配置：

为什么Curl正常但Chrome不行？ #

• curl --limit-rate之所以能让WebFlux降速，是因为curl会严格按照你指定的速率去读取响应，TCP层面的滑动窗口会给服务器传递“我暂时接收不了更多数据”的信号，WebFlux作为响应式框架能感知到这个背压，自然会放慢发送速度。
• 但Chrome不一样，它有个默认的预加载/缓存优化：不管你的JS代码消费速度有多慢，浏览器会主动把整个响应提前下载到本地缓存里，这时候服务器看到的是“客户端在快速接收数据”，自然会全速发送，而你的JS只是从浏览器缓存里慢慢拿数据，所以才会出现write()只收到187kB，但实际下载了32MB的情况。

你的JS代码可能存在的问题 #

虽然浏览器缓存是主因，但如果你的Streams API消费逻辑没正确触发背压，也会让服务器没法感知到你真实的消费速度。常见的坑有这两个：

1. 没控制读取节奏，一次性发起所有读取请求 #

比如有些同学会写类似这样的代码：

const reader = response.body.getReader();
// 错误：没等待处理完成就循环读取，相当于告诉浏览器“我能快速消费”
async function readNonStop() {
  while (true) {
    const { done, value } = await reader.read();
    if (done) break;
    // 直接处理，不等待异步操作完成
    processChunk(value); 
  }
}
readNonStop();

这种写法会让浏览器不断向服务器请求数据，完全忽略你的处理速度，服务器自然会全速发送。

2. 忽略了Streams API的背压机制 #

Streams API的背压是通过等待上一次read()的Promise完成后再发起下一次读取来实现的。如果你的代码没有遵循这个逻辑，就没法给浏览器传递“我现在处理不过来”的信号，浏览器还是会提前缓存所有数据。

修正方案 #

要让服务器真正感知到你的消费速度，得从JS代码和服务器配置两方面入手：

方案一：严格控制Stream的读取节奏 #

确保每次处理完当前数据块后，再发起下一次读取，这样浏览器的读取速度会被你的JS逻辑限制，间接给服务器传递背压信号。示例代码：

async function consumeStream(response) {
  const reader = response.body.getReader();
  let totalReceived = 0;

  while (true) {
    const { done, value } = await reader.read();
    if (done) {
      console.log('Stream处理完成');
      break;
    }

    // 模拟你的慢消费逻辑，比如写入本地或者做计算
    await writeToYourTarget(value); 
    // 如果你的处理是同步的，可以加个延迟模拟慢消费：await new Promise(resolve => setTimeout(resolve, 100));
    
    totalReceived += value.length;
    console.log(`已接收 ${totalReceived} 字节`);
  }
}

// 发起请求时记得设置合适的请求头，避免浏览器做额外的缓存优化
fetch('/your-webflux-endpoint', {
  headers: {
    'Accept': 'application/octet-stream',
    'Cache-Control': 'no-cache'
  }
})
.then(response => consumeStream(response))
.catch(err => console.error('请求出错:', err));

方案二：服务器端配置禁用缓存并启用分块传输 #

在WebFlux的响应中添加禁用缓存和分块传输的头，让浏览器没法提前缓存整个响应，只能按块接收：

// Java示例，WebFlux的响应处理
response.headers()
    .setCacheControl(CacheControl.noCache().mustRevalidate())
    .set(HttpHeaders.TRANSFER_ENCODING, "chunked");

这样浏览器会被迫逐块接收数据，此时你的JS消费速度就能直接影响服务器的发送速度了。

验证方法 #

你可以打开Chrome DevTools的Network标签，找到这个请求，查看Timing面板：

• 如果数据是逐步接收的（Timing里的“Content Download”阶段是分段的），说明背压生效了；
• 如果是一次性下载完成，那说明浏览器还是缓存了整个响应，可能需要调整请求头或者服务器配置。

另外也可以在服务器端加个日志，记录每个数据块的发送时间，看看是否和你的JS消费速度匹配。

内容的提问来源于stack exchange，提问作者Ryan Holdren