断点续传需服务端支持Range请求并返回206状态码及Content-Range头；客户端用fetch手动添加Range头、累加receivedBytes、配合指数退避重试，并可选localStorage存偏移量校验ETag恢复。
JavaScript 中处理流式传输中断后的断点重试连接，核心在于：**记录已接收数据位置 + 服务端支持范围请求（Range） + 客户端主动恢复请求**。浏览器原生的 fetch 或 XMLHttpRequest 本身不自动续传，需手动实现逻辑。
服务端必须支持 HTTP Range 请求
这是断点续传的前提。服务端需正确响应 Range: bytes=1024- 这类请求，并返回：
-
206 Partial Content状态码 -
Content-Range响应头（如bytes 1024-9999/10000） -
Accept-Ranges: bytes表明支持分段
若服务端不支持，客户端即使携带 Range 头，也会返回完整资源（200）或报错，无法真正续传。
用 fetch + ReadableStream 手动管理断点
推荐使用 fetch 配合 ReadableStream 和 Uint8Array 缓冲区，记录已写入字节数：
立即学习“Java免费学习笔记（深入）”；
- 首次请求不带
Range，或从0开始；获取响应后读取response.headers.get('content-length')得总大小 - 每次接收
chunk后累加长度，存入变量（如receivedBytes） - 中断后，下次请求时在
headers中添加：{ 'Range': `bytes=${receivedBytes}-` } - 注意：恢复请求仍需检查响应状态是否为
206，否则说明服务端不支持或范围越界
网络恢复后自动重试 + 指数退避
监听网络状态变化，结合重试策略避免频繁无效请求：
- 用
navigator.onLine初步判断，但更可靠的是捕获fetch的NetworkError或超时 - 重试前等待延迟（如 1s → 2s → 4s），可用
setTimeout实现简单指数退避 - 设置最大重试次数（如 5 次），失败后可提示用户或降级为重新开始
- 避免在重试中重复写入已接收部分——只把新
chunk追加到已有数据末尾
存储断点位置（可选但推荐）
页面刷新或意外关闭后仍需恢复，可将当前接收偏移量暂存：
- 使用
localStorage或IndexedDB保存{ url, offset, totalSize, timestamp } - 恢复时先查本地缓存，再发
HEAD请求校验资源是否变更（比对ETag或Last-Modified） - 若资源已更新（
ETag不一致），清空本地断点，从头下载
