JS实现断点续传的几种方式

JS实现断点续传，核心在于将大文件分割成小块，逐个上传或下载，并记录传输进度。客户端利用`Blob.slice()`切片，通过HTTP请求头的`Range`字段指定数据范围，结合`localStorage`或`IndexedDB`持久化进度信息。服务器需支持`206 Partial Content`状态码，通过`Content-Range`告知客户端返回的是文件的哪一部分。客户端与服务器需约定API端点、请求头、响应头、状态码，以及分片识别和合并策略。大文件上传需考虑分片大小、并发上传、失败重试、进度持久化等问题，下载则依赖`Range`请求头和服务器的`206`响应，配合本地存储和错误恢复机制，确保大文件传输的高效与稳定。

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

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

最核心的技术点无疑是 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 头，以此判断是否支持。

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

1. Blob 拼接: 将每次下载到的 Blob 数据追加到一个大的 Blob 中。这对于较小的文件可能可行，但对于非常大的文件，内存消耗会成为问题。
2. FileSaver.js 或类似库: 这些库可以帮助将 Blob 保存为文件。但它们通常是覆盖式保存，而不是追加。
3. 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 并发送整个文件，提示客户端重新开始下载。这对于确保文件完整性非常重要。

再者，HTTP 状态码的约定：

• 200 OK: 通常表示请求成功，且返回了完整资源（或上传成功）。
• 206 Partial Content: 表示服务器成功处理了 Range 请求，返回了部分内容。这是断点续传下载的关键状态码。
• 416 Range Not Satisfiable: 客户端请求的范围无效，例如超出了文件大小。
• 400 Bad Request / 500 Internal Server Error: 常规的错误处理。

还有，分片识别和合并策略：

• 文件唯一标识: 客户端上传时，需要给文件一个唯一ID（比如文件的MD5哈希值），这样服务器就知道所有分片都属于同一个文件。
• 分片索引/偏移量: 服务器需要知道每个分片在整个文件中的位置，以便正确地合并。客户端在上传时，通常会发送分片的索引或起始字节偏移量。
• 服务器端存储: 服务器需要有临时存储空间来存放接收到的分片，并在所有分片上传完成后将它们合并成完整的文件。

最后，并发与限流。客户端可以并发上传多个分片，但服务器也需要有能力处理这些并发请求，并且可能需要对单个客户端的并发连接数进行限制，防止资源耗尽。同时，服务器可能需要处理“脏数据”或不完整上传的清理工作，比如在一定时间后清理未完成的临时文件。

整个过程，就像是客户端和服务器在玩一个拼图游戏，客户端把拼图块一块块地送过去，并且告诉服务器这块放在哪里；服务器负责接收、校验，并把它们拼起来。中间如果出了问题，双方得有办法知道是哪一块出了问题，然后从那里重新开始。

好了，本文到此结束，带大家了解了《JS实现断点续传的几种方式》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！