断点续传通过文件分片与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
头，以此判断是否支持。
在客户端，收到这些部分数据后，我们需要将其正确地组装起来。这通常意味着你需要一个能够写入特定文件位置的机制。在浏览器环境中，直接写入文件系统是受限的。常见的做法是：
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
并发送整个文件，提示客户端重新开始下载。这对于确保文件完整性非常重要。
再者，HTTP 状态码的约定：
200 OK
: 通常表示请求成功，且返回了完整资源（或上传成功）。
206 Partial Content
: 表示服务器成功处理了
Range
请求，返回了部分内容。这是断点续传下载的关键状态码。
416 Range Not Satisfiable
: 客户端请求的范围无效，例如超出了文件大小。
400 Bad Request
/
500 Internal Server Error
: 常规的错误处理。
还有，分片识别和合并策略：
文件唯一标识: 客户端上传时，需要给文件一个唯一ID（比如文件的MD5哈希值），这样服务器就知道所有分片都属于同一个文件。分片索引/偏移量: 服务器需要知道每个分片在整个文件中的位置，以便正确地合并。客户端在上传时，通常会发送分片的索引或起始字节偏移量。服务器端存储: 服务器需要有临时存储空间来存放接收到的分片，并在所有分片上传完成后将它们合并成完整的文件。
最后，并发与限流。客户端可以并发上传多个分片，但服务器也需要有能力处理这些并发请求，并且可能需要对单个客户端的并发连接数进行限制，防止资源耗尽。同时，服务器可能需要处理“脏数据”或不完整上传的清理工作，比如在一定时间后清理未完成的临时文件。
整个过程，就像是客户端和服务器在玩一个拼图游戏，客户端把拼图块一块块地送过去，并且告诉服务器这块放在哪里；服务器负责接收、校验，并把它们拼起来。中间如果出了问题，双方得有办法知道是哪一块出了问题，然后从那里重新开始。
以上就是JS如何实现断点续传的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1517542.html
微信扫一扫 
支付宝扫一扫 
