大文件分片上传和合并怎么实现？

wen PHP项目 2026-06-05 49

从原理到实战的完整指南

目录导读

为什么需要分片上传？—— 核心痛点解析
分片上传的核心原理与流程
前端实现：如何切割与上传文件分片
后端实现：如何接收分片并完成合并
断点续传与进度追踪的落地方案
常见问题与性能优化策略
问答环节：开发者最关心的10个问题

为什么需要分片上传？—— 核心痛点解析

当用户尝试上传一个2GB的视频文件时,传统单次上传可能面临以下问题：

HTTP请求超时：浏览器或服务器默认超时时间通常为60-120秒,大文件传输容易中断。
内存溢出：一次性读取大文件会耗尽浏览器内存,导致页面崩溃。
网络波动导致全盘重传：一旦失败，必须从头开始,用户体验极差。

分片上传的核心价值在于：将大文件拆分为多个小块（例如每块5MB），独立上传，最后在服务端合并，这种方式不仅降低了单次请求的负载，还支持断点续传,显著提升成功率。

分片上传的核心原理与流程

整个流程分为四个阶段：

初始化

前端计算文件MD5哈希值，并向服务端发起“创建上传任务”请求，服务端返回一个唯一 uploadId,用于标识该文件。

分片上传

前端按固定大小（如5MB）切割文件,得到多个分片。
每个分片携带分片索引（partNumber）和 uploadId,独立上传。
服务端收到分片后,验证MD5并临时存储。

合并请求

所有分片上传完成后，前端发送 merge 请求，携带 uploadId 和所有分片列表,服务端按索引顺序拼接成完整文件。

校验与清理

服务端验证完整文件的MD5是否与初始化时一致，若一致则返回最终访问URL,并清理临时分片。

前端实现：如何切割与上传文件分片

1 计算文件哈希（推荐使用SparkMD5库）

function calculateHash(file) {
  return new Promise((resolve, reject) => {
    const spark = new SparkMD5.ArrayBuffer();
    const reader = new FileReader();
    const chunkSize = 2 * 1024 * 1024; // 2MB
    let offset = 0;
    reader.onload = (e) => {
      spark.append(e.target.result);
      offset += chunkSize;
      if (offset < file.size) {
        readChunk();
      } else {
        resolve(spark.end());
      }
    };
    reader.onerror = reject;
    function readChunk() {
      const slice = file.slice(offset, offset + chunkSize);
      reader.readAsArrayBuffer(slice);
    }
    readChunk();
  });
}

2 切割文件并并发上传

async function uploadInChunks(file, chunkSize = 5 * 1024 * 1024) {
  const totalChunks = Math.ceil(file.size / chunkSize);
  const uploadId = await getUploadId(hash); // 初始化获取uploadId
  const uploadPromises = [];
  for (let i = 0; i < totalChunks; i++) {
    const start = i * chunkSize;
    const chunk = file.slice(start, start + chunkSize);
    // 使用FormData包裹分片
    const formData = new FormData();
    formData.append('chunk', chunk);
    formData.append('uploadId', uploadId);
    formData.append('partNumber', i + 1);
    // 并发控制：限制同时上传5个分片
    uploadPromises.push(uploadChunkWithRetry(formData, i));
  }
  await Promise.all(uploadPromises);
  // 触发合并
  await mergeRequest(uploadId, totalChunks);
}

3 断点续传的实现

进度存储：每次成功上传分片后，将 partNumber 存入 localStorage 或 IndexedDB。
恢复逻辑：初始化时先查询已上传的分片列表,跳过已完成的分片。
服务端接口示例：GET /api/upload/progress?uploadId=xxx 返回已收到的分片索引。

后端实现：如何接收分片并完成合并

1 分片接收接口（以Node.js + Express为例）

app.post('/api/upload/chunk', upload.single('chunk'), async (req, res) => {
  const { uploadId, partNumber } = req.body;
  const chunk = req.file;
  const chunkPath = `./tmp/${uploadId}_${partNumber}`;
  // 保存分片到临时目录
  fs.writeFileSync(chunkPath, chunk.buffer);
  // 记录分片状态到数据库
  await db.insert({ uploadId, partNumber, path: chunkPath, status: 'done' });
  res.json({ code: 0, message: '分片上传成功' });
});

2 合并分片

app.post('/api/upload/merge', async (req, res) => {
  const { uploadId, totalChunks } = req.body;
  const records = await db.select({ uploadId }).orderBy('partNumber');
  const targetPath = `./uploads/${uploadId}.mp4`;
  const writeStream = fs.createWriteStream(targetPath);
  for (const record of records) {
    const chunkBuffer = fs.readFileSync(record.path);
    writeStream.write(chunkBuffer);
    fs.unlinkSync(record.path); // 删除临时分片
  }
  writeStream.end();
  // 校验最终文件MD5
  const finalMd5 = await computeFileMd5(targetPath);
  if (finalMd5 === uploadId) { // uploadId可以设计为初始MD5
    res.json({ url: `/download/${uploadId}.mp4` });
  } else {
    res.status(500).json({ error: '文件校验失败' });
  }
});

注意：生产环境建议使用流式合并，避免内存溢出，可参考 pipeline 方法。

断点续传与进度追踪的落地方案

1 进度获取

前端显示：每个分片上传通过 XMLHttpRequest.upload.onprogress 获取单个分片进度,累计后计算整体进度。
后端反馈：合并请求前，前端调用 GET /api/upload/progress?uploadId=xxx 获取已上传分片数,用于界面恢复。

2 多线程优化

使用 Web Worker 在后台计算哈希,避免阻塞UI。
并发上传分片（建议数量：5~10个），通过队列控制并发数,避免网络拥塞。

3 错误处理与重试

每个分片设置独立重试机制：失败后等待2秒重试,最多重试3次。
服务端接口需支持幂等性：同一 uploadId + partNumber 重复上传时,覆盖旧分片。

常见问题与性能优化策略

问题1：哈希计算太慢怎么办？

使用 增量计算：读取文件时边读边计算MD5,而非读完整个文件。
采样计算：仅对文件开头+中间+结尾部分计算哈希，用于快速校验（但准确率略低）。

问题2：分片大小如何选择？

网络带宽大：建议4MB~8MB,减少请求次数。
网络不稳定：建议1MB~2MB,减少失败重传成本。
综合考虑：5MB是行业常见平衡点。

问题3：服务器磁盘空间不足？

设置分片过期时间（如30分钟）,超时未合并自动清理。
使用对象存储（如OSS、S3）支持直接分片上传,无需临时存储。

性能优化清单

优化点	方案
减少请求数	适当增大分片大小（但不超过10MB）
减少IO等待	使用内存缓存 + 异步写入
合并加速	多线程合并（需考虑磁盘顺序读写）
网络开销	启用HTTP/2多路复用

问答环节：开发者最关心的10个问题

Q1：分片上传一定要先初始化吗？
A：是的，初始化用于创建任务记录，返回唯一标识,防止不同文件混淆。

Q2：如何保证分片顺序正确？
A：每个分片携带 partNumber，服务端按序号排序后合并，前端需保证上传顺序正确，但并发上传可能导致乱序到达,服务端应在所有分片到达后统一排序。

Q3：分片丢失后如何发现？
A：合并时检查 totalChunks 与接收到的分片数是否一致，不一致则返回错误状态,前端触发重传缺失分片。

Q4：能否支持暂停上传？
A：可以，前端取消所有未完成的上传请求，并保存当前进度，恢复时重新查询服务端已接收的分片列表,跳过已完成的分片。

Q5：浏览器支持哪些切割方式？
A：使用 File.prototype.slice() 方法，兼容Chrome、Firefox、Edge、Safari（需注意Safari对大文件切割的稳定性）。

Q6：服务端合并时内存不足怎么办？
A：使用流式写入，逐块读取并写入文件，避免一次加载所有分片，例如Node.js中 fs.createReadStream + fs.createWriteStream。

Q7：分片上传的MD5校验有必要吗？
A：强烈建议，可以防止传输过程中数据损坏，尤其在弱网络环境下，但注意计算MD5会增加CPU开销，可在初始化时计算一次完整文件MD5，分片校验使用快速哈希（如CRC32）。

Q8：如何支持移动端上传？
A：移动端网络波动更频繁，建议分片大小设为2MB~3MB，并发数降低至3个，使用 navigator.onLine 检测网络状态，实现自动暂停/恢复。

Q9：多文件上传时如何管理多个uploadId？
A：前端维护一个 Map<fileId, uploadTask>，每个任务包含 uploadId、进度、状态，使用事件总线或状态管理库（如Redux）统一调度。

Q10：如果用户上传一半关闭了浏览器怎么办？
A：服务端定期清理过期分片（如1小时内未合并），用户重新打开页面后，前端检查本地缓存的上传进度，恢复上传,也可结合数据库持久化进度。

大文件分片上传本质是 “空间换时间” 的分布式思维：拆分风险点，并行处理，最终聚合成完整结果，实现时需要平衡前端用户体验、后端资源消耗和网络稳定性，掌握本文的核心流程与优化策略，即可应对99%的大文件上传场景，建议从简单的2~3个分片开始调试，逐步增加并发数和分片数量，验证边界情况（如恰好整除、小于分片大小等），在实际项目中，还可结合业界成熟的方案（如阿里云OSS分片上传、腾讯云COS分片上传）进行二次开发。