如何识别同一个上传

断点续传的核心

分片上传把失败成本从「整个文件」降到「某个分片」，但用户真正需要的是：页面刷新、网络断开、浏览器崩溃后，能从已经完成的部分继续上传。

断点续传的核心不是「继续传文件」，而是可靠地识别同一个上传任务，并知道哪些分片已经可信。

识别同一文件的三条路

客户端重新进入页面后，需要重新找到上传任务：

生产系统怎么选

生产系统通常不会一次性在前端计算完整大文件 hash（几百 MB 全读一遍很慢），而是：

• 用抽样 hash（取文件头、中、尾若干块计算）或边读边算做第一层识别。
• 把 upload_id 缓存在本地（如 IndexedDB），重新进入页面优先复用。
• 服务端仍然做最终校验，不能完全信任客户端报的 hash。

识别到任务的三种结果

客户端带着候选身份去服务端确认时，可能有三种结果：

• 任务存在且未完成 → 继续传缺失分片。
• 任务已完成 → 直接进入合并 / 可用状态（这就是「秒传」的雏形）。
• 任务不存在 / 已过期 → 重新初始化上传任务。

服务端是权威

无论客户端用什么策略，最终可信的是服务端：

• 服务端以 upload_id + 分片编号 + hash 为准。
• 客户端「自认为已经传过的」分片，服务端要能查询确认（下一节的状态查询）。
• 内容完整性和真实性，合并时由服务端再次校验。

下一节看断点续传的状态查询与幂等设计。

上一章节

断点续传

下一章节

状态查询与幂等设计