Fetch 传输大文本内存占用分析

本文深入剖析了使用 Fetch API 传输大文本时的内存占用陷阱，指出真正导致内存暴涨的并非网络传输本身，而是 `.text()`、`.json()` 等方法一次性将整个响应体解码并载入内存所引发的指数级开销——例如100MB UTF-8数据可能在JS中膨胀至300MB；通过Chrome内存快照精准定位基底占用，并对比验证：流式处理（`response.body.getReader()` + `TextDecoder`）可将峰值内存稳定控制在5–10MB，彻底规避OOM与卡顿，让超大文本（如320MB日志）解析从崩溃边缘变为流畅可控的确定性操作。

识别 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，全程无卡顿

本质上，流不是“更快”，而是“可控”。它把不可预测的内存爆炸，换成可估算、可中断、可降级的确定性行为。

今天关于《Fetch 传输大文本内存占用分析》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！