JS如何实现断点续传

小老鼠

发布时间：2025-08-24 13:42:02

974人浏览过

来源于php中文网

原创

断点续传通过文件分片与HTTP Range/Content-Range头实现，客户端用Blob.slice切片，结合fetch/XHR传输，localStorage或IndexedDB持久化进度，服务器需支持206状态码与分片合并，上传时带Content-Range标识位置，下载时用Range请求续传，双方通过文件ID、偏移量、ETag等约定协同，配合并发控制、重试机制与完整性校验，确保大文件传输高效稳定。

js如何实现断点续传

JavaScript 实现断点续传，核心在于将大文件分割成小块（分片），然后逐个上传或下载这些小块，同时记录传输进度。当传输中断时，可以从中断的位置继续，而不是从头开始。这通常涉及到客户端的文件切片能力（如

Blob.slice()

），HTTP 请求头中的

Range

字段来指定数据范围，以及本地存储（如

localStorage

或

IndexedDB

）来持久化进度信息。

JS实现断点续传，它本身不是一个单一的API调用，而是一套基于Web标准和服务器协作的策略。

解决方案

断点续传的实现，无论是上传还是下载，都围绕着“分而治之”的理念。

在上传场景中，过程大致是这样：用户选择一个文件，浏览器通过

File

对象的

slice

方法（它是

Blob.prototype.slice

的一个实现）将文件切割成若干个固定大小的二进制数据块（

Blob

或

ArrayBuffer

）。客户端会维护一个已上传分片的列表或一个总进度条。每一个分片通过

XMLHttpRequest

或

fetch

发送到服务器。关键在于，请求头中需要带上

Content-Range

字段，告诉服务器当前这个分片是整个文件的哪一部分（例如：

Content-Range: bytes 0-1048575/104857600

，表示这是从0字节到1MB的片，总文件大小100MB）。服务器接收到分片后，会将其暂存，并根据

Content-Range

信息将其拼接到正确的位置。服务器通常还会返回一个成功状态码（如

200 OK

或

201 Created

），客户端收到后更新进度。如果传输过程中断（比如网络问题、浏览器关闭），客户端在下次尝试上传时，会先查询服务器（或者从本地存储读取）已经成功上传了多少分片。例如，服务器可以提供一个接口，返回某个文件ID已经上传的字节数，或者已上传分片的索引列表。客户端拿到这个信息后，就从下一个未上传的分片开始继续传输。

在下载场景中，原理类似但方向相反：客户端发起一个下载请求时，如果支持断点续传，它会检查本地是否已经有部分文件（比如上次下载中断留下的）。如果存在部分文件，客户端会通过

Range

请求头（例如：

Range: bytes=1048576-

，表示从1MB开始请求剩余部分）向服务器请求文件的剩余部分。服务器如果支持断点续传，会返回

206 Partial Content

状态码，并在响应头中包含

Content-Range

，以及从指定字节开始的数据。客户端接收到数据后，将其追加到本地已有的文件部分。如果下载中断，下次可以再次发送

Range

请求，从上次中断的位置继续。

核心技术点：

Blob.prototype.slice()
: 用于在客户端将文件切片。
XMLHttpRequest
或
fetch
API: 发送HTTP请求。
HTTP
Range
请求头: 用于下载时请求文件的一部分。
HTTP
Content-Range
请求头: 用于上传时指示当前分片在整个文件中的位置。
HTTP
206 Partial Content
响应码: 服务器返回部分内容时的状态码。
本地存储:
```
localStorage
```
或
```
IndexedDB
```
用于保存上传/下载的进度、文件ID、已完成分片索引等信息，以便在页面刷新或浏览器关闭后恢复。

如何处理大文件上传的性能与稳定性问题？

处理大文件上传，真的不只是把文件切开然后一股脑儿扔出去那么简单。这里面涉及到很多细节，一不小心就会遇到各种奇怪的瓶颈。

首先，分片大小的选择是个艺术。太小了，HTTP请求的开销（握手、头部信息）就会变得非常显著，服务器可能被大量的短连接请求压垮，网络延迟的影响也会放大。想想看，一个1GB的文件，如果每片1KB，那就是100万个请求，这简直是噩梦。但如果分片太大，一旦某个分片上传失败，就需要重传更大的数据量，而且在网络状况不佳时，大分片更容易超时。通常，我会考虑1MB到10MB之间，这算是一个比较均衡的范围，但具体还得看网络环境和服务器性能。

其次，并发上传。理论上，同时上传几个分片能提高吞吐量，减少总上传时间。但这里有个度，并发太多会迅速耗尽客户端的带宽，甚至可能触发浏览器的连接限制，服务器也可能因为连接数过多而拒绝服务。我通常会限制并发数在3-6个，这在多数情况下是比较安全的。实现上，可以维护一个队列，每次只处理固定数量的请求，当一个请求完成后，再从队列中取出下一个。

再来，失败重试机制是必不可少的。网络波动是常态，某个分片上传失败太常见了。一个好的策略是，当一个分片上传失败时，不要立即放弃，而是尝试重试几次。可以采用指数退避的策略，即每次重试的间隔时间逐渐增加，这样可以避免在网络短暂抖动时频繁重试导致更大的负担。同时，需要明确失败的类型，是网络错误、服务器错误还是其他。对于某些错误，可能需要用户手动干预。

然后是进度持久化。上传过程中，用户可能会刷新页面，或者浏览器崩溃。如果进度没有保存，那之前的努力就白费了。将已上传分片的索引或已上传字节数保存到

localStorage

或

IndexedDB

是非常关键的。这样，下次打开页面时，可以读取这些信息，从上次中断的地方继续上传。

最后，别忘了用户体验。一个清晰的进度条、上传速度显示、剩余时间预估，以及友好的错误提示，都能极大地提升用户满意度。当上传遇到问题时，直接告诉用户哪里出错了，而不是让他们一脸茫然。

断点续传在下载场景中如何应用，有哪些技术细节？

下载场景下的断点续传，其实是

Range

请求头和服务器

206 Partial Content

响应的完美结合。这不像上传那么需要复杂的切片逻辑，更多的是关于如何有效地管理下载流和本地数据。

BGremover

VanceAI推出的图片背景移除工具

下载

最核心的技术点无疑是 HTTP

Range

请求头。当客户端想要从文件的某个字节位置开始下载时，它会在请求头中加入

Range: bytes=start-end

。如果想下载从某个位置到文件末尾，就是

Range: bytes=start-

。例如，

Range: bytes=102400-

就表示从第102400个字节开始下载。

服务器端必须支持这个功能。它需要检查请求头中的

Range

字段，如果支持，就返回

206 Partial Content

状态码，并在响应头中包含

Content-Range

（例如

Content-Range: bytes 102400-204799/1048576

，表示当前返回的是总文件1MB中的100KB到200KB的部分），以及实际的二进制数据。如果服务器不支持

Range

请求，它通常会返回

200 OK

并发送整个文件，这就不支持断点续传了。所以，客户端在发起下载前，有时会先发送一个HEAD请求，检查服务器是否返回

Accept-Ranges: bytes

头，以此判断是否支持。

在客户端，收到这些部分数据后，我们需要将其正确地组装起来。这通常意味着你需要一个能够写入特定文件位置的机制。在浏览器环境中，直接写入文件系统是受限的。常见的做法是：

Blob 拼接: 将每次下载到的 Blob 数据追加到一个大的 Blob 中。这对于较小的文件可能可行，但对于非常大的文件，内存消耗会成为问题。
FileSaver.js
或类似库: 这些库可以帮助将 Blob 保存为文件。但它们通常是覆盖式保存，而不是追加。
Service Worker: 这是一个更强大的方案。Service Worker 可以在后台运行，拦截网络请求，并拥有
```
Cache API
```
和
```
IndexedDB
```
的能力。你可以利用
```
IndexedDB
```
来存储下载的各个片段，然后在下载完成后将它们组装起来。这使得即使关闭页面，下载也能在后台继续。

进度持久化在下载中同样重要。你需要记录已下载的字节数、文件的总大小，以及下载的URL等信息，并将其保存在

IndexedDB

中。这样，当用户重新访问页面时，可以从上次中断的位置继续下载。

错误恢复方面，如果某个片段下载失败，同样需要重试机制。可以针对性地重试失败的

Range

请求。同时，要考虑文件完整性校验，例如下载完成后计算文件的哈希值，与服务器提供的哈希值进行比对，确保文件没有损坏。

客户端与服务器端在实现断点续传时需要哪些协作与约定？

断点续传绝不是客户端或服务器单方面就能搞定的事情，它需要双方紧密的协作和一套明确的约定，就像两个人跳双人舞，步调不一致就容易踩脚。

首先，API 端点和请求方法。服务器需要提供清晰的API接口来处理分片上传和下载。对于上传，可能是一个

POST

或

PUT

请求，接收文件分片。对于下载，则是一个

GET

请求。这些接口需要能够识别是哪个文件的哪个部分。

其次，HTTP 请求头和响应头约定是核心中的核心：

Range
(客户端 -> 服务器): 客户端在请求下载文件的某个部分时使用，格式如
```
bytes=start-end
```
。
Content-Range
(服务器 -> 客户端，或客户端 -> 服务器):
- 服务器在响应
```
206 Partial Content
```
  时，用它来告诉客户端返回的是总文件的哪一部分，格式如
```
bytes start-end/totalLength
```
  。
- 客户端在上传分片时，用它来告诉服务器当前分片是总文件的哪一部分，格式同上。
Accept-Ranges
(服务器 -> 客户端): 服务器在响应
```
200 OK
```
或
```
206 Partial Content
```
时，可以包含这个头，值为
```
bytes
```
，表明它支持按字节范围请求。客户端可以据此判断是否可以进行断点续传。
Content-Length
: 无论上传还是下载，这个头都表示当前请求或响应体的长度。在下载时，如果服务器返回
```
200 OK
```
，它表示整个文件的大小；如果返回
```
206 Partial Content
```
，它表示当前分片的大小。
ETag
/
Last-Modified
: 这些是文件内容的唯一标识或最后修改时间。客户端可以在下次请求时带上
```
If-Range
```
头，如果文件在服务器上没有变化，服务器可以直接返回
```
206
```
；如果文件有变化，则返回
```
200
```
并发送整个文件，提示客户端重新开始下载。这对于确保文件完整性非常重要。