流式上传的关键是数据边生成边传输且不缓存全量，需同时满足：body为原生readablestream实例、start中按需enqueue小块、网络面板显示请求体分段增长。
流式上传的核心识别点
判断一个 fetch 请求是否真正实现了流式上传，关键不是看有没有用 ReadableStream，而是看数据是否「边生成、边传输、不缓存全量」。普通 fetch 的 body: string | Blob | ArrayBuffer 会在发起请求前全部加载进内存；而流式上传的 body 必须是浏览器原生的 ReadableStream 实例，且该流由应用主动控制分块产出。
确认 Request Body 是真实流的三步验证
在代码中，以下三点同时满足，才能认定是真正的流式上传：
-
body 选项直接传入 new ReadableStream() 或自定义流实例，而非通过
new Blob([...]).stream()这类“伪流”（后者只是把 Blob 包装成流，实际仍需先构造完整 Blob） -
流的 underlyingSource.start() 方法中，不预先生成全部数据，而是按需调用
controller.enqueue()推送小块（如每次 64KB 的 Uint8Array），并配合异步逻辑（如读取文件片段、生成加密块、拼接日志行） -
fetch 调用后，网络面板（Network tab）中能看到请求体（Request Payload）持续增长、分段发送，而不是一次性出现完整大小 —— 这说明 HTTP 协议层启用了
Transfer-Encoding: chunked，服务端也在接收过程中实时处理
常见误判场景与规避方式
很多开发者以为用了 .stream() 就是流式，其实容易踩坑：
- Blob.stream() 不等于流式上传：Blob 构造本身会把全部内容载入内存，再转成流只是形式转换，对大文件毫无内存优势
- Response.body 有流 ≠ Request.body 支持流：fetch 流式下载（response.body）是广泛支持的，但流式上传（request.body）依赖服务端明确接受流，并且浏览器需支持 WHATWG Fetch 规范中对 request body stream 的定义（Chrome 99+、Firefox 110+、Safari 16.4+ 已稳定支持）
-
未设置正确 Content-Type 可能导致流被缓冲：例如传
'Content-Type': 'application/json'时，某些网关或中间件会等待完整 body 才解析；推荐用'application/octet-stream'或自定义类型（如'application/x-ndjson-stream'），并和服务端约定按块解析逻辑
一个可验证的真实流式上传示例
以下代码启动后，不会立刻占用数百 MB 内存，而是每 200ms 推送一段随机字符串，网络请求体随时间逐步增长：
const stream = new ReadableStream({
start(controller) {
let count = 0;
const interval = setInterval(() => {
if (count >= 50) {
controller.close();
clearInterval(interval);
return;
}
const chunk = new TextEncoder().encode(`chunk-${count++}\n`);
controller.enqueue(chunk);
}, 200);
}
});
await fetch('/upload', {
method: 'POST',
headers: { 'Content-Type': 'application/octet-stream' },
body: stream
});
打开 DevTools → Network → 查看该请求的「Size」列，你会看到它从 “(pending)” 逐渐变为 “12 KB”、“24 KB”……直到结束 —— 这就是流式上传在协议层的直观体现。
