Chunked Upload Lab

可交互的大文件上传实验站

Chunked
Upload Lab

把大文件拆成小块，稳定、并发、可恢复地传到服务端。

拖入文件即可观察 Hash、切片、并发传输和流式合并。暂停后继续、失败后重试， 已上传的分片不会重复发送。

  • 4 MiB 智能分片
  • 秒传与断点续传
  • 1–8 路并发
  • Web Worker 哈希
立即体验分片上传工作原理拆解

Data Channel

17/32 已上传 · 并发 4

FILE

原始文件

video.mp4

128 MB · Blob.slice 可按需切割

HASH

Worker 内计算

5f4dcc3b5aa765d61d8327deb882cf99

MD5 · SparkMD5 增量计算，主线程不卡

CHUNK

并发上传

4 MiB / 片 · 原子写入 chunks/<hash>/<index>.part

MERGE

服务端流式

.uploads/merged/5f4dcc3b….bin

按 index 顺序流式拼接，不落两倍内存

上传工作区

选择一个文件，看看分片如何流动

文件只在需要时读取为分片；Hash 在独立线程计算，上传过程不会阻塞页面交互。

4(1–8)

对新任务立即生效；进行中的上传槽位不变，「恢复 / 重试」时按新值调度。

5M

把大文件拖到这里

支持多文件 · 4 MiB 分片 · 可暂停与恢复Hash → Check → Upload chunks → Merge

暂无任务。把文件拖到上方区域即可开始上传。

一次上传的完整旅程

从一个文件，到一组可恢复的分片

完整原理拆解

  1. 01

    切片与哈希

    Blob.slice 切成 4 MiB 分片；SparkMD5 在 Web Worker 里增量算出整文件 MD5。

  2. 02

    三态判定

    check 接口按服务端目录给出秒传 / 续传 / 全新三种结论，决定还要传哪些片。

  3. 03

    并发上传

    分片进入并发池（1–8 可调），单片失败按 1s / 2s / 4s 指数退避重试。

  4. 04

    流式合并

    服务端按 index 顺序流式拼接分片，产物落在 merged/<hash>.bin。

秒传是怎么命中的？

check 接口拿着文件 MD5 去看 .uploads/merged/<hash>.bin 是否存在：存在即「秒传」，直接返回下载链接，一个分片都不用传。 所以同一个文件第二次拖进来，只会看到哈希计算那一段进度。

断点续传恢复了什么？

merged 不存在时，check 会扫描 .uploads/chunks/<hash>/ 目录，把已落盘的分片 index 列表返回；客户端跳过这些分片，只传缺口。 暂停、刷新、甚至换一天再传，都走同一条路径——服务端文件系统就是唯一的会话状态。