前端fetch无法流式读取的根源常是后端协议违规：响应头同时含Transfer-Encoding: chunked与Content-Length（HTTP/1.1禁止共存）；TCP抓包显示单一大包而非多个小包；或后端手动设chunked头却未按规范输出分块体（缺长度前缀、未flush、无0\r\n\r\n结尾），导致浏览器解析失败。
前端 fetch 无法进入流式读取（response.body.getReader() 或 response.body.pipeThrough()），往往不是代码写错了，而是后端响应在协议层“假装支持流”，实际却破坏了 chunked 编码规则。识别这类问题，关键看三点：响应头是否合规、响应体是否真实分块、中间件是否偷偷改写。
看响应头有没有 Transfer-Encoding: chunked，且没有 Content-Length
这是最基础的准入条件。如果响应中同时出现：
- Transfer-Encoding: chunked，但
- Content-Length 也存在（哪怕值是 0 或任意数字）
那浏览器或 fetch API 会直接拒绝流模式——HTTP/1.1 协议明确要求二者互斥。Content-Length 表示整包已知长度，chunked 表示动态分块，共存即矛盾。常见于 Nginx、Tomcat 或代理层自动注入 Content-Length（比如 gzip 压缩后计算了长度，但没清除 chunked 头）。
抓包确认 TCP 层是否真有多个小包陆续到达
仅看响应头不够，得验证传输行为。用 Wireshark 或 tcpdump 抓取服务端返回的原始 TCP 流：
立即学习“前端免费学习笔记（深入）”；
- 如果只看到 1 个大 TCP 包（比如几百 KB 一次性发完），说明后端或中间件（如 ALB、Cloudflare、Nginx 的
proxy_buffering on）在缓冲整个响应，根本没走流式发送； - 如果看到 多个小 TCP 包按序到达（每个包含类似
7\r\nHello\r\n这样的结构），且最后以0\r\n\r\n结束，才表明 chunked 真正在工作。
注意：有些代理（如 IIS ARR）默认缓冲 ≤4MB 响应并重写为 Content-Length，即使后端发的是 chunked，客户端也收不到 chunked 头。
检查后端是否手动设置了 chunked 头，但没按规范输出响应体
典型反模式：Java/Spring 中用 response.setHeader("Transfer-Encoding", "chunked") 强行加头，但响应体仍是普通 write（未逐块 flush、未加十六进制长度前缀、未以 0\r\n\r\n 结尾）。此时：
- 浏览器收到 chunked 头，开始按分块协议解析；
- 但实际数据没有 chunk 格式，很快遇到连接关闭或乱码，触发
net::ERR_INCOMPLETE_CHUNKED_ENCODING； - fetch 的
response.body可能为 null 或抛出 TypeError。
正确做法是交由 Web 容器（如 Tomcat、Undertow）或框架（如 Spring WebFlux、Node.js Stream）自动处理 chunked 编码，而不是手写头+手写体。
排查中间件是否静默移除或覆盖 chunked 头
很多网关和反向代理默认不信任或不透传 chunked：
- Nginx 默认开启
chunked_transfer_encoding on，但若上游响应带Content-Length，它可能优先用后者并删掉 chunked 头； - IIS ARR 默认缓冲响应，需将
Response Buffer Threshold设为 0 才透传 chunked； - Cloudflare、AWS ALB 等托管负载均衡器，可能对非标准响应头过滤或强制缓冲，尤其当响应含 CORS、gzip 等头时。
验证方法：绕过所有中间层，curl 直连后端服务，对比响应头与 TCP 行为是否一致。
