大文件断点续传

断点续传在浏览器中实现“刷机后不丢失”需要综合考虑前端和后端的设计。以下是实现思路和常用方案：

1. 使用唯一文件标识（文件哈希或唯一ID）：

   • 在上传前，计算文件的唯一标识（如MD5、SHA-1等）或由用户提供的唯一ID。

   • 通过存储在浏览器本地（localStorage、IndexedDB）中的上传状态，记录已上传的片段或进度。

2. 断点续传机制（块级上传）：

   • 将文件切分成多个块（chunk），每个块单独上传。

   • 在上传过程中，记录已上传的块信息（比如已完成的块编号）。

   • 浏览器刷新后，从本地存储读取上传状态，继续上传未完成的块。

3. 持久存储上传状态：

   • 使用浏览器的localStorage或IndexedDB保存上传的进度信息。

   • IndexedDB适合存储大量二进制数据和结构化信息，稳定性更强。

4. 后端支持：

   • 后端需要支持断点续传，比如支持Range请求或分块上传（如FastDFS、MinIO、OSS、AWS S3的Multipart Upload等）。

   • 要求后端能识别文件（通过唯一文件ID）和已上传的块信息。

5. 技术实现建议：

   • 前端： 通过 FileReader 或 Blob.slice() 将文件切片。

   • 上传： 每次上传一块，上传成功后，更新本地存储的状态。

   • 刷新后： 读取本地状态，从未完成的块开始继续上传。

6. 案例示意（伪代码）：

// 获取文件唯一标识（如hash）
const fileHash = await computeFileHash(file);
​
// 读取已上传块信息
const uploadedChunks = getFromLocalStorage(fileHash) || [];
​
// 切分文件
const chunks = createChunks(file, chunkSize);
​
// 遍历块，检测已上传部分
for (let i=0; i 
  

注意事项：

• 数据安全：确保上传的块有校验（如MD5校验）。

• 多次失败重试：重新上传失败的块。

• 存储空间管理：清理上传完成的记录。

总结：

通过结合前端的断点续传技术（分块、状态存储）和后端的支持（支持断点续传的存储方案），可以实现刷新后不丢失上传状态，达到“断点续传”的效果。