在当前的Web开发环境中，用户上传几兆的文档或许轻而易举，但一旦面对几百兆甚至几个G的视频素材、工程压缩包或高清镜像文件，传统的表单提交方式瞬间就会失效。浏览器超时、服务器内存溢出、网络波动导致前功尽弃，这些问题如果不解决，用户体验将灾难性地下降。要在前端用JavaScript优雅地搞定大型文件上传，不能只靠一个简单的<input>标签，必须深入到底层网络协议和文件操作API，采用“化整为零”的分片策略，并配合完善的容错机制。
一、传统上传模式的致命瓶颈
要理解为什么需要特殊方案，先得看清传统方式的死穴。常规的<form>表单提交或基础的XMLHttpRequest一次性发送整个文件，本质上是建立一个长连接，将文件流从头传到尾。在这个过程中，只要网络出现哪怕一秒的抖动，或者服务器端因为处理超时而切断连接，整个传输就会中断。用户只能眼睁睁看着进度条卡在99%，然后被迫从头开始。
更严重的是服务器端的压力。一次性接收大文件意味着服务器必须在内存中缓冲大量数据，或者频繁地进行磁盘IO操作。在高并发场景下，几个大文件同时上传就能瞬间吃光服务器内存，导致服务崩溃。此外，浏览器的默认超时设置通常较短，对于耗时几分钟的大文件传输，浏览器往往会主动判定请求失败。这些痛点决定了，大型文件上传必须抛弃“一口吃成胖子”的思维，转向分片处理。
二、核心策略：文件切片与并发控制
解决大文件上传的核心思路只有一个：分片上传（Chunked Upload）。利用HTML5提供的File API，我们可以像切蛋糕一样，将一个大文件切割成若干个固定大小的小块（例如每块2MB），然后逐个或并发上传这些小块。
1. 利用Blob.slice进行物理切割
File对象继承自Blob，因此可以直接使用slice方法截取文件的一部分。代码逻辑非常直观：计算文件总大小，设定每个切片的大小（chunkSize），通过循环计算出每个切片的起始位置（start）和结束位置（end），调用file.slice(start, end)生成新的Blob对象。这个新生成的Blob对象只包含原文件的一小段二进制数据，体积小巧，传输极快。
在实现时，切片大小的设定是一门学问。切得太小，会产生大量的HTTP请求头开销，增加服务器握手负担；切得太大，又失去了分片的意义，重试成本高。通常建议根据网络环境动态调整，或者固定在2MB到5MB之间。
2. 并发队列管理
拿到切片后，是直接一股脑全发出去，还是一个个排队发？全部并发虽然理论速度最快，但会瞬间占满浏览器的连接数（浏览器对同一域名的并发连接数通常限制在6个左右），导致部分请求排队甚至超时。完全串行则浪费了带宽。
最佳实践是维护一个“并发池”。设定一个最大并发数（如4个），先填充池子发送前4个切片。每当有一个切片上传成功，就从池中移除，并立即从等待队列中取出下一个切片补位。这种“流水线”作业方式既能跑满带宽，又能避免连接阻塞。在JS中，可以通过Promise配合递归或async/await结合计数器来轻松实现这种调度逻辑。
三、关键难点：断点续传与秒传机制
分片上传只是第一步，真正的价值在于它能支持“断点续传”和“秒传”，这是提升用户体验的杀手锏。
1. 基于哈希的文件指纹识别
要实现断点续传，前后端必须对“哪个文件传到了哪一步”有共同的认知。最可靠的方法是为文件生成一个唯一的“指纹”，通常使用spark-md5库计算文件内容的MD5值。在上传开始前，前端先计算整个文件的MD5（注意：计算大文件MD5本身也耗时，建议使用Web Worker在后台线程计算，避免卡死主线程界面），然后将这个MD5值发送给后端。
后端收到MD5后，查询数据库或文件系统：
- 情况A：如果该MD5对应的文件已完整存在，直接返回“上传成功”。前端无需传输任何数据，实现“秒传”。
- 情况B：如果该MD5存在，但文件不完整（之前传过一部分），后端返回已上传的切片索引列表（例如：[0, 1, 3, 5]）。前端拿到列表后，跳过这些索引，只上传缺失的切片（2, 4, 6…）。
- 情况C：如果是新文件，后端返回空列表，前端从头开始上传所有切片。
2. 服务端的状态合并
前端负责分片发送，后端负责“拼图”。服务器接收到每一个切片时，不能直接覆盖文件，而是要根据文件名或唯一标识，将数据追加写入到一个临时文件中，或者先存储在临时目录。只有当所有切片都上传完毕，前端发送一个“合并请求”时，服务器才将所有临时碎片合并成一个完整的文件，并清理临时数据。
这里要注意并发写入的问题。如果多个用户同时上传同名文件或相同内容的文件，后端必须有锁机制或独立的临时存储空间，防止数据错乱。通常的做法是使用“用户ID + 文件MD5 + 时间戳”作为临时文件的唯一命名规则。
四、异常处理与交互体验优化
大型文件上传周期长，网络环境复杂，代码的健壮性至关重要。
1. 自动重试机制
网络波动是常态。某个切片上传失败是大概率事件。不能因为一个切片失败就让用户重新上传整个文件。需要在代码中加入重试逻辑：当某个切片的请求失败（如超时、500错误）时，自动捕获异常，暂停一小段时间（如1秒、2秒、4秒指数退避），然后重新发送该切片。只有当重试次数超过阈值（如3次）依然失败，才向用户报错，提示检查网络。
2. 精准的进度反馈
用户最需要的是确定性。由于是分片上传，总的进度不能简单依赖单个XHR的onprogress事件。我们需要自己维护一个全局进度变量：已上传切片总大小 / 文件总大小 * 100%。每成功上传一个切片，就累加其大小，更新进度条。这样即使用户暂停后再继续，进度条也能准确接上之前的状态，而不是从零开始。
3. 暂停与取消功能
基于分片机制，实现“暂停”非常简单：只需停止从等待队列中取新的切片发送，并终止当前正在进行的请求即可。所有的上传状态（已传切片索引）都保存在服务端或通过本地缓存记录。用户点击“继续”时，重新触发一次“查询已传切片”的逻辑，接着传剩下的部分。这种可控性是一次性上传完全无法比拟的。
五、后端对接的注意事项
前端做得再好，后端不支持也是白搭。在设计后端接口时，通常需要三个核心接口：
- 验证接口：接收文件MD5，返回已上传的切片列表或秒传指令。
- 上传接口：接收文件切片（二进制流）、文件MD5、切片索引、总分片数。服务端将流写入临时文件。
- 合并接口：接收文件MD5、文件名。服务端校验所有切片是否到齐，执行合并操作，生成最终文件。
此外，还要考虑安全性。必须校验上传文件的类型（MIME Type）和扩展名，防止恶意脚本上传。对于超大文件，服务器的max_body_size配置需要调大，或者配置Nginx/Apache以支持流式写入，避免内存溢出。
大型文件上传是一个系统工程，考验的是对网络协议、文件IO和异步流程控制的综合驾驭能力。通过分片、并发、断点续传这一套组合拳，我们不仅能解决技术难题，更能给用户带来丝滑流畅的操作体验。
