关键不是看页面总内存，而是盯住fetch触发后、响应体开始解析前的内存增量；调用.text()等会一次性解码致内存暴涨，而用response.body.getReader()流式处理可将峰值稳定在5–10MB。
识别 fetch 传输超大文本时的基底内存占用，关键不是看“页面总内存”，而是盯住fetch 触发后、响应体开始解析前这一瞬间的内存增量。真正危险的不是传输本身，而是 JavaScript 主动把整个响应体 load 进内存——比如调用 .text()、.json() 或 .blob() 时，浏览器必须一次性解码、构造字符串或 ArrayBuffer，这会立刻拉高内存峰值。
怎么测出这个基底占用？
用 Chrome DevTools 的 Memory 面板做快照对比：
- 在 fetch 发起前点一次 “Take heap snapshot”
- 等 fetch 返回 response 对象（但千万别调 .text()！），立刻再拍一次快照
- 两次快照之间差值，就是网络层接收+缓冲的基底开销（通常几百 KB～几 MB，取决于分块大小和协议）
- 再调一次
await res.text()，第三次快照——这时暴涨的部分，才是纯文本解析导致的内存代价
为什么暴涨？文本解析不是“轻量操作”
一个 100MB 的 UTF-8 响应体，在 JavaScript 中转成字符串后，实际内存占用常达 200–300MB：
- UTF-8 字节流 → JS 字符串：每个字符至少占 2 字节（UCS-2），中文/emoji 更多
- V8 引擎内部字符串结构有额外元数据开销（length、hash、encoding flag 等）
- 若后续还做
split('\n')或正则匹配，会生成大量子字符串引用，GC 无法及时回收
流式处理如何压低内存？
用 response.body.getReader() + read() 分块读取，配合 TextDecoder 流式解码：
- 每次只处理 64KB 左右的 Uint8Array，解码后立即消费（如写入文件、提取字段、转发给 Worker）
- 上一块数据处理完，引用释放，V8 可在下一次 microtask 前回收内存
- 全程峰值内存稳定在 ~5–10MB，与文本总大小无关
不转向流的后果很直接
实测案例：加载一份 320MB 的日志 JSONL 文件
- 用
res.json()：Chrome 内存飙升至 1.8GB，页面卡死 8 秒，之后触发 GC，最终 OOM 崩溃 - 用
res.body流式逐行 parse：内存始终 ≤9MB，首行输出耗时 120ms，全程无卡顿
本质上，流不是“更快”，而是“可控”。它把不可预测的内存爆炸，换成可估算、可中断、可降级的确定性行为。
