大文件秒传原理：为什么一个 MD5 就能判断文件不用上传？

做网盘、视频上传、AI 知识库文件上传时，经常会看到一个体验：

选择一个几百 MB 的文件，几乎瞬间就提示“上传成功”。

几百 MB 的文件不可能真的一瞬间传到服务器。

所谓秒传，本质上并没有再次上传文件。

它真正做的是：

计算文件指纹
    ↓
询问服务器这个文件是否已经存在
    ↓
如果存在
    ↓
直接复用服务器已有文件

这就是秒传最核心的原理。

一、秒传为什么要计算 MD5？

假设用户上传一个：

Java教程.zip

不能直接通过文件名判断它有没有上传过。

因为：

Java教程.zip

这个名字可能对应很多完全不同的文件。

所以客户端通常会先计算整个文件的 MD5：

文件内容
   ↓
MD5
   ↓
8d7e...xxxx

同一个文件内容，通常会得到相同的 MD5。

于是服务器可以把：

fileMd5

当成文件内容的“指纹”。

需要注意，MD5 在这里主要是用于文件识别和去重，而不是安全校验。对于安全敏感、存在恶意碰撞风险的系统，可以考虑使用 SHA-256 等方案。

二、秒传完整流程

正常上传大文件之前，前端先做一件事情：

选择文件
   ↓
计算文件 MD5
   ↓
调用“文件检查接口”

例如：

fileMd5 = abc123...

服务器收到 MD5 后查询数据库。

接下来会出现三种情况。

情况一：服务器从来没有这个文件

数据库没有记录

说明文件从未上传。

服务器告诉前端：

文件不存在
需要上传

前端继续：

切分文件
   ↓
上传分片
   ↓
服务器合并

这就是一次完整的新文件上传。

三、情况二：文件已经完整上传

如果服务器查询发现：

MD5 已存在
+
文件已经上传完成

那么完全没有必要重新传一次。

服务器直接告诉前端：

文件已存在
无需上传

前端立即显示：

上传成功

这就是所谓的：

秒传

所以所谓秒传其实可以理解为：

服务器发现自己已经有这份文件，于是跳过真实的文件传输过程。

四、情况三：文件上传过，但是没传完

这是大文件上传里非常有意思的一种情况。

例如一个文件被切成：

100 个分片

用户之前已经上传：

然后：

网络断开
浏览器关闭
电脑关机

如果第二天重新上传时直接从：

第 0 个分片

重新开始，非常浪费。

所以服务器查询 MD5 后发现：

文件记录存在
但是状态还是“上传中”

这时候再查询：

已经上传了哪些分片

例如：

0 ~ 35

然后返回给前端。

前端就可以：

跳过 0 ~ 35
继续上传 36 ~ 99

这就是：

断点续传

所以实际上：

秒传
断点续传
分片上传

并不是三个完全独立的功能。

它们是一整套大文件上传方案。

五、三者之间到底是什么关系？

整个流程可以画成：

用户选择文件
      ↓
计算文件 MD5
      ↓
检查服务器
      ↓
   文件存在吗？
    ↙       ↘
   否        是
   ↓         ↓
正常上传   上传完成了吗？
             ↙      ↘
            是       否
            ↓        ↓
           秒传    查询已有分片
                     ↓
                  断点续传

所以“文件检查接口”其实是整个上传流程的入口。

它决定了后面到底走：

秒传

还是：

断点续传

还是：

完整上传

六、为什么还需要一张分片表？

只保存：

文件 MD5
总分片数量
已经上传数量

其实还不够。

因为：

uploadedChunks = 36

只能说明上传了 36 个分片。

但不能保证上传的是：

0 ~ 35

也可能是：

所以更稳妥的方案是单独记录：

文件 MD5
分片编号
分片大小
分片存储位置

这样服务器才能准确告诉客户端：

哪些分片已经存在

前端只上传缺少的部分。

七、文件状态也非常重要

一个文件通常不能只有：

存在
不存在

两个状态。

因为真实业务中可能经历：

上传中
   ↓
上传完成
   ↓
待处理
   ↓
处理中
   ↓
处理完成

例如 AI 知识库：

文件上传
   ↓
分片合并
   ↓
Markdown 解析
   ↓
文档切片
   ↓
Embedding
   ↓
向量数据库

所以：

数据库有文件记录

并不等于：

文件已经完整上传

秒传判断一定要结合文件状态。

否则可能出现：

数据库记录存在
↓
实际上只上传了一半
↓
系统却告诉用户“秒传成功”

这显然是不对的。

八、一个比较合理的判断逻辑

后端拿到文件 MD5 后，核心判断其实非常简单：

查询 MD5
   ↓
没有记录
   ↓
完整上传


查询 MD5
   ↓
记录存在
   ↓
文件已完整上传
   ↓
秒传


查询 MD5
   ↓
记录存在
   ↓
仍处于上传中
   ↓
查询已有分片
   ↓
断点续传

因此一个文件检查接口，通常只需要告诉前端三个信息：

文件是否存在

是否还需要上传

已经上传了哪些分片

前端拿到这些信息以后，就可以决定下一步怎么走。

总结

秒传看起来很高级，但原理其实非常简单。

它并不是把：

1GB 文件

在一秒钟内传到了服务器。

而是：

客户端计算文件指纹
        ↓
服务器根据指纹检查文件
        ↓
发现相同文件已经存在
        ↓
跳过上传

而如果文件只上传了一部分，则进一步查询已有分片：

找到已上传分片
        ↓
跳过它们
        ↓
继续上传剩余分片

于是就形成了一整套：

MD5 文件检查
      ↓
   秒传判断
      ↓
   分片上传
      ↓
   断点续传
      ↓
   分片合并

理解这套流程之后，会发现所谓秒传的核心不是“上传得快”，而是“根本不重复上传”。