传个2G的视频传到90%断了？大文件上传三种方案对比

系统里一有文件上传需求，"传大文件"的坑迟早要踩：工厂要传质检视频，设计部要传几百 M 的图纸包，现场要传设备录像。普通表单上传在这种量级面前全面失灵：传到一半网络抖一下前功尽弃，超时设置调再大也挡不住弱网环境。

核心矛盾是：HTTP 单次请求模型是为"小而快"设计的，大文件传输需要把"一次成功"的不确定性，拆解成"多次小成功"的确定性。 业界有三条主流路线：分片并行上传、断点续传、文件秒传，实战中常组合使用，但解决的问题各有侧重。

方案一：分片并行上传

原理： 前端把文件切成固定大小的分片（比如每片 5M），并发上传，每片带序号和文件指纹；服务端收齐所有分片后按序合并。单点故障只影响一个分片，重传粒度从"整个文件"降到"一个分片"。

优点：

• 失败成本骤降：网络抖动最多丢一个 5M 的分片，不再全军覆没
• 并发提速：多线程同时传多个分片，带宽利用率拉满
• 进度精确：按分片计算的进度条平滑真实，用户体验好

缺点：

• 实现复杂度上来：分片管理、合并逻辑、失败重试都要自己写
• 服务器临时存储压力：海量分片的暂存和清理要有机制
• 合并大文件时的 IO 和耗时要处理，不能让用户在 99% 卡住

适用场景： 所有大文件上传的基础方案。配合对象存储的原生分片接口（S3 Multipart、COS 分块上传）使用，服务端复杂度能降一大半。

方案二：断点续传

原理： 在分片基础上，上传前向服务端查询"这个文件传了哪些分片"，已传成功的分片直接跳过，只补传缺失部分。刷新页面、断网重连、隔天再传，都接着上次的进度走。

优点：

• 弱网救星：网络多差都能"蚂蚁搬家"传完
• 用户零焦虑：中途关掉页面不心疼，回来接着传
• 节省流量：重复上传的场景不再浪费带宽

缺点：

• 状态管理复杂：上传会话的标识、过期、清理要完整设计
• 分片记录要可靠：记录丢了等于重新传，存储介质选型要想清楚
• 文件变更检测：本地文件改过了但指纹没变更是经典 bug，指纹算法要涵盖内容

适用场景： 现场环境差的上传场景：工厂车间、工地、移动网络。质检视频、巡检录像这类"必须传上去"的业务文件，断点续传是刚需不是加分项。

方案三：文件秒传（指纹去重）

原理： 上传前先计算文件指纹（MD5、SHA-256 或分片采样哈希），向服务端查询指纹是否存在；已存在则直接建立文件引用，跳过传输过程。同一个文件，第二个上传的人"秒传"。

优点：

• 传输成本归零：重复文件不再占用任何带宽
• 存储成本骤降：相同文件只存一份，引用计数管理
• 用户体验惊艳：几个 G 的文件"秒传成功"

缺点：

• 指纹计算有成本：大文件全量哈希要读一遍磁盘，前端要做异步和进度提示
• 隐私边界要想清楚：秒传意味着服务端知道"你也有一份一样的文件"，敏感场景要评估
• 哈希碰撞的理论风险：重要文件建议哈希 + 文件大小双重校验

适用场景： 重复率高的业务场景：标准图纸分发回传、培训视频多网点上传、模板类文件。重复率低的场景收益有限，别为了秒传而秒传。

按业务场景对号入座

成熟方案通常是三件套：指纹先行（能秒传就不传），传则分片（并发提速），断则续传（失败可恢复）。对象存储的 SDK 大多内置了这三件套，自研前先看云厂商给了什么。

落地前必做的三件事

第一件：分片大小要权衡。 分片太小（1M 以下），请求数量爆炸，HTTP 开销吃掉收益；太大（50M 以上），单分片失败成本回升。公网环境 5M 到 10M 是经验甜区，内网可以适当放大。

第二件：垃圾分片要有清理机制。 用户传了一半永远不回来，分片就成了存储垃圾。上传会话设过期时间（比如 7 天），过期分片定时清理，存储账单才不会悄悄长胖。

第三件：安全校验不能省。 文件类型白名单、病毒扫描、大小限制，在合并完成后、正式入库前执行。分片上传把文件拆散了，安全校验的时机设计不对，恶意文件可能绕过检查。

写在最后

大文件上传的技术核心就一句话：把一次大赌博拆成多次小确幸。分片解决"失败成本"，续传解决"环境恶劣"，秒传解决"重复浪费"，按需取用。但比技术方案更重要的是运维细节：分片清理、指纹设计、安全校验，这些才是上线后真正见功夫的地方。