前端传输100GB文件至后端的内存限制问题与方案咨询

你当前的整包上传逻辑完全不适用于100GB级别的大文件，存在几个致命问题：

• 没有分片处理：虽然现代浏览器fetch传FormData包裹File对象理论上会走流式传输不会全量读入内存，但单请求传100GB文件一旦网络波动、连接中断，就要从头重新上传，实际使用中几乎不可能成功
• 无断点续传能力：上传中途关闭页面、断网、浏览器崩溃，之前传输的内容全部作废
• 无进度感知：用户看不到实时上传进度，无法判断是传输卡顿还是正常运行，很容易中途终止操作
• 超时拦截风险：单请求持续几十分钟甚至数小时，很容易触发浏览器默认超时限制、网关层超时拦截，直接导致上传失败
• 后端接收压力大：单请求承载100GB数据流，如果后端没有配套的流式落盘逻辑，很容易直接打满服务内存

行业内通用的大文件上传方案是分片上传+断点续传，全程不会把完整文件读入JS内存，完全可以避开单标签4GB内存限制，核心流程如下：

前端侧逻辑 #

1. 用户选中文件后，不要直接把整个File对象塞进FormData，首先设置固定分片大小（一般设为5MB~20MB，可根据网络环境调整），计算总分片数：totalChunks = Math.ceil(file.size / chunkSize)
2. 上传前先调用后端预上传接口，传入文件唯一标识（简单场景可用文件大小+文件名+最后修改时间生成，高准确率场景可抽样计算文件hash，注意算hash时也要按分片读取，不要全量加载文件）、文件名、总分片数，后端返回已经上传成功的分片序号列表
3. 遍历所有分片序号，跳过已经上传完成的分片，用file.slice(start, end)方法切出对应分片的Blob对象——这个slice是浏览器提供的零拷贝接口，不会把整个文件读入内存，只会在发送时按需读取对应分片的二进制内容
4. 每个分片单独发POST请求传给后端，请求中携带当前分片序号、文件唯一标识、总分片数，支持并发传输多个分片（一般并发数设为3~6，避免占满带宽导致其他请求阻塞）
5. 监听每个分片的上传进度，汇总为整个文件的上传进度展示给用户
6. 所有分片传输完成后，调用后端合并接口，通知后端把所有分片按序号拼接为完整文件，合并完成后返回最终文件访问地址

前端核心分片代码参考 #

const CHUNK_SIZE = 10 * 1024 * 1024; // 单分片大小设为10MB
const uploadFile = async (file) => {
  const totalChunks = Math.ceil(file.size / CHUNK_SIZE);
  // 预上传，获取已上传分片列表和当前任务唯一ID
  const { uploadedChunks, fileId } = await fetch('/api/upload/init', {
    method: 'POST',
    headers: {'Content-Type': 'application/json'},
    body: JSON.stringify({
      fileName: file.name,
      fileSize: file.size,
      totalChunks
    })
  }).then(res => res.json());

  // 生成待传分片队列
  const pendingChunks = [];
  for (let i = 0; i < totalChunks; i++) {
    if (uploadedChunks.includes(i)) continue;
    const start = i * CHUNK_SIZE;
    const end = Math.min(start + CHUNK_SIZE, file.size);
    const chunk = file.slice(start, end);
    pendingChunks.push({ index: i, chunk });
  }

  // 按顺序传分片，实际场景可加并发池、失败重试逻辑
  for (const task of pendingChunks) {
    const fd = new FormData();
    fd.append('fileId', fileId);
    fd.append('chunkIndex', task.index);
    fd.append('chunk', task.chunk);
    await fetch('/api/upload/chunk', {
      method: 'POST',
      body: fd
    });
    // 更新上传进度
    console.log(`上传进度：${Math.round((task.index + 1)/totalChunks * 100)}%`);
  }

  // 所有分片传完，通知后端合并
  await fetch('/api/upload/merge', {
    method: 'POST',
    headers: {'Content-Type': 'application/json'},
    body: JSON.stringify({ fileId })
  });
}

后端侧配套逻辑 #

1. 预上传接口：接收文件元信息，为每个上传任务生成唯一fileId，记录任务信息，检查临时存储目录下已存在的分片，返回给前端实现断点续传
2. 分片接收接口：接收前端传来的单个分片，直接以fileId-分片序号为文件名落盘到临时目录，不要把分片内容暂存在内存中
3. 合并接口：确认所有分片上传完成后，按分片序号从小到大的顺序，把所有分片文件追加写入到最终目标文件，写入完成后删除临时分片文件
4. 可选加过期清理逻辑：定期清理长时间未完成上传的临时分片文件，避免占用过多磁盘空间

• 失败重试：单个分片传输失败后自动重试2~3次，不需要重传整个文件
• 并发控制：维护固定大小的并发请求池，完成一个分片请求再补充下一个，不要一次性发起所有分片请求
• 秒传功能：预上传阶段如果后端发现已经存在相同标识的完整文件，可直接返回上传成功，不需要重复传输
• Hash计算优化：不要全量读取文件计算MD5（100GB文件全量算hash需要数十分钟），可使用Web Worker在后台计算，或采用抽样hash（取文件头、中间段、文件尾各几MB内容+文件大小+修改时间生成标识），平衡准确率和计算速度

关键注意点：全程不要用FileReader读取整个文件的内容做处理，所有分片操作都基于File.slice()实现，浏览器底层会做流式读取，任意时刻内存中最多只有正在传输的几个分片的大小，完全不会触达4GB的单标签内存上限。

内容的提问来源于stack exchange，提问作者Megidd