Fetch API配合ReadableStream可实现真正的流式读取，而XMLHttpRequest仅支持整体加载完成后触发load事件，无法中途访问部分数据；XHR的progress事件仅能获知已加载字节数，但受压缩、编码和格式限制，无法安全分块解析。
JavaScript 中 Ajax 并不使用 V8 引擎提供的“XHR 对象”——V8 是 JavaScript 引擎，负责执行 JS 代码，但 XMLHttpRequest（XHR）是浏览器环境提供的 Web API，由浏览器内核（如 Blink、WebKit）实现，V8 不提供也不管理 XHR。因此，“用 V8 的 XHR 对象”这一说法存在根本性误解。
XHR 本身不支持真正的流式读取或分块解析
XMLHttpRequest 的 responseType 支持 "text"、"arraybuffer"、"blob" 等，但其设计是**整体加载完成后再触发 load 事件**。即使设置 responseType = "arraybuffer"，你也无法在下载中途访问已接收的部分数据——xhr.response 在请求结束前始终为空或不完整。
虽然可通过监听 progress 事件获知已加载字节数（event.loaded），但无法安全地切片或解析未完成响应体，因为：
- 响应体可能被压缩（如 gzip），浏览器在解压完成前不暴露原始字节
- 文本编码（如 UTF-8）可能跨 chunk 断开，直接截断会导致乱码
- JSON、CSV 等结构化格式需完整解析，中间状态不可靠
真正可行的分块流式读取方案：Fetch + ReadableStream
现代浏览器中，只有 fetch() 配合 Response.body（即 ReadableStream）才能实现真正的流式读取。它允许你逐段读取、解析、释放内存，适合处理 GB 级日志、大 CSV 或 JSON Lines 数据。
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
示例：分块读取一个 JSON Lines 文件（每行一个 JSON 对象）
const response = await fetch('/large-data.jsonl');
const reader = response.body.getReader();
const decoder = new TextDecoder();
while (true) {
const { done, value } = await reader.read();
if (done) break;
const chunk = decoder.decode(value, { stream: true });
// 按换行符拆分，注意处理跨 chunk 的行
// （实际需维护缓冲区，避免行被截断）
}
若必须兼容老浏览器（无 ReadableStream）：模拟分块请求
当目标环境不支持 ReadableStream（如 IE、旧版 Safari），可退而求其次，用 XHR 分多次请求数据片段：
- 后端提供分页或 range 接口（如
GET /data?offset=0&limit=10000） - 前端顺序/并发发起多个 XHR 请求，每次处理一个块
- 用
Range请求头读取文件某一段（需服务端支持Accept-Ranges）
注意：这不是“流式”，而是“分片拉取”，需服务端配合，且无法实时响应上传进度或处理动态生成的大响应。
关键提醒：别混淆引擎与运行时
V8 负责执行 JS，但网络能力（XHR、fetch、WebSocket、Stream）均由宿主环境（浏览器或 Node.js）提供。Node.js 中甚至没有 XHR，而是用 node-fetch 或 undici；而 Deno、Bun 等运行时也各自实现自己的 I/O 接口。理解这个边界，才能选对技术路径。
