根因：浏览器要收完整文件（所有字节到齐）才能处理。就像寄一个 500kg 的包裹，你必须等全部到货才能拆——不能边到边拆。

1.2 关键概念：HTTP Range 请求

HTTP/1.1 支持一个叫 Range 的请求头——可以只请求文件的指定字节范围：

GET /big-file.pdf
Range: bytes=0-1048575    ← 只要前 1MB


服务器返回：
206 Partial Content
Content-Range: bytes 0-1048575/524288000    ← 总共 500MB，返回了 0-1MB
Accept-Ranges: bytes                         ← 告诉你「我支持分片」

服务器发送：[chunk1][chunk2][chunk3]...[chunkN]
浏览器接收：←────── 流（Stream）──────←

const res = await fetch('/big-file.pdf')
const blob = await res.blob()  // 等所有数据到齐
window.open(URL.createObjectURL(blob))  // 打开

// 只下前 1MB（PDF 前几页通常在这范围内）
const res = await fetch('/big-file.pdf', {
  headers: { Range: 'bytes=0-1048575' },
})
const firstChunk = await res.arrayBuffer()  // 1MB
// 立刻用这 1MB 预览（PDF 前 N 页）
preview(firstChunk)


// 后台继续下剩余部分

const FILE_SIZE = 524288000  // 500MB
const CHUNK_SIZE = 10485760   // 每片 10MB
const CONCURRENCY = 4          // 4 个并发连接


// 把文件分成 50 个 10MB 的片
const chunks = planChunks(FILE_SIZE, CHUNK_SIZE)


// 4 个连接并行下载（Semaphore 控制并发数）
await parallelDownload(chunks, CONCURRENCY, async (chunk) => {
  const res = await fetch('/big-file.pdf', {
    headers: { Range: `bytes=${chunk.start}-${chunk.end}` },
  })
  chunk.data = await res.arrayBuffer()
})

const res = await fetch('/big-file.pdf')
const reader = res.body.getReader()  // 流式读取


let received = 0
while (true) {
  const { done, value } = await reader.read()  // 读一块（几 KB ~ 几十 KB）
  if (done) break


  received += value.length


  // 每收到一块就尝试渐进渲染（如 PDF 渲染引擎收到足够数据就渲染下一页）
  appendChunk(value)
  updateProgress(received)  // 实时进度（字节级精确）
}

PDF 渲染引擎（如 pdf.js）：
  收到前 100KB → 解析 PDF header + 目录 → 显示「共 N 页」
  收到前 1MB → 渲染第 1-3 页（通常在前部）
  收到前 5MB → 渲染第 4-10 页
  ...渐进渲染，用户边看边等后续页

// HLS：video 元素直接播放 m3u8（Safari 原生 / Chrome 用 hls.js）
video.src = '/stream.m3u8'  // 天然分片，边下边播

音频：跟视频类似

• MP3 / AAC：按帧分片，每帧独立解码，可以按帧流式播放。

• 浏览器原生：<audio> 元素天然流式（跟 video 一样）。

• 波形预览：提取波形数据（不需解码全部音频，只取峰值）

const audio = new Audio('/audio.mp3')  // 浏览器原生流式
audio.play()

文档：元数据在尾部（最反直觉）

关键洞察：PDF 和 DOCX 的元数据在文件尾部。所以分片下载要先跳到文件尾部读结构，再按需加载内容。

PDF 的结构

PDF 文件
├── 页面数据（页 1, 2, 3... 的渲染指令）
└── 交叉引用表（xref）  ← 告诉你「第 N 页在文件的第 X 字节」
    （xref 在文件尾部！）

分片预览策略（pdf.js 就这么做）：

① Range 请求文件尾部（最后 1KB，含 xref）
② 从 xref 解析出「第 1 页在第 X-Y 字节」
③ Range 请求只下第 1 页的数据
④ pdf.js 渲染第 1 页 → 用户立刻看到
⑤ 后台继续按需加载其他页

DOCX / XLSX 的结构（本质是 ZIP）

DOCX 文件（= ZIP）
├── word/document.xml（正文）
├── word/media/（图片）
└── 中央目录（Central Directory）  ← 告诉你「每个 XML 在 ZIP 的第 X 字节」
    （中央目录在 ZIP 尾部！）

分片预览策略：

① Range 请求文件尾部（ZIP 中央目录）
② 从目录解析出 document.xml 的位置
③ Range 请求只下 document.xml
④ 解析 XML → 渲染文档内容

TXT / CSV / JSON（纯文本）

天然流式——从头逐行读取，不需要跳尾部（没有尾部元数据）。

const reader = res.body.getReader()
while (true) {
  const { done, value } = await reader.read()
  if (done) break
  appendText(new TextDecoder().decode(value))  // 每收到一块就追加显示
}

为什么文档最特殊？

图片 / 视频 / 音频的元数据在文件头（从头读就行）。但 PDF / DOCX 的元数据在文件尾——你必须先跳到尾部才能知道结构。这是 Range 请求最有价值的地方：

图片/视频/音频：Range 0-1MB（从头部开始）
文档（PDF/DOCX）：Range 最后 1KB（跳到尾部读元数据）→ 再按结构 Range 加载

这个「先跳尾部」的洞察是文档分片预览的核心——也是为什么 pdf.js 能实现「500 页 PDF 瞬间打开第 1 页」的原因。

Part 5 · 场景选型：怎么选对方法

决策树

你的文件多大？
│
├─ 小文件（< 10MB）
│   └─ 整体下载（Step 1，简单够用）
│
├─ 中文件（10-100MB）
│   ├─ 需要快速预览 → Range 分片先下前面（Step 2）
│   └─ 加速下载 → 多连接并发（Step 3）
│
├─ 大文件（100MB-1GB）
│   ├─ 需要边下边看 → 流式渐进预览（Step 4）
│   ├─ 弱网环境 → 断点续传（Step 5）
│   └─ 网络不稳定 → 自适应分片（Step 6）
│
└─ 超大文件 / 频繁更新（> 1GB / 版本同步）
    └─ CDC 增量同步（Step 7）

Step 1  整体下载             → 干等（下完才开）
Step 2  HTTP Range 分片      → 先下前面预览
Step 3  多连接并发           → 带宽拉满加速
Step 4  流式渐进预览         → 边下边看（字节级进度）
Step 5  断点续传             → 断网不白下（IndexedDB + SHA-256）
Step 6  自适应分片           → 网络感知动态调整大小
Step 7  CDC 增量同步         → 只传改动块（rsync/Dropbox）

阅读原文：点击这里