分块大文件上传触发SBOX_FATAL_MEMORY_EXCEEDED内存异常问题

• 最核心的内存消耗来自readAsDataURL的转换逻辑：每一块二进制分块会被转成体积膨胀*33%*的base64字符串，加上原代码全程复用同一个FileReader实例，所有历史转换生成的大字符串被闭包持续持有，垃圾回收无法及时回收内存，随着上传进度推进，累计驻留的字符串内存会快速涨到数GB，最终触发浏览器沙箱内存超限崩溃。
• 其次是jQuery ajax的序列化开销：把大体积base64字符串作为普通字段传入ajax的data参数时，jQuery会在请求准备阶段对字符串做全量序列化、拷贝，额外生成一份完整的字符串副本，直接把内存占用再抬升一档。
• 重试逻辑的内存挂起问题：触发重试时直接重复调用reader.readAsDataURL，没有主动清空上一次转换生成的reader.result引用，导致待回收的内存被持续挂起，无法被释放。
• 原代码的进度统计逻辑存在错误：Loaded += e.loaded的计算方式不对，e.loaded是单次FileReader读取内部的进度值，不是分块的实际大小，容易造成切片位置错位，进一步加剧内存浪费。

1. 从根源砍掉base64转换的高内存开销 #

• 直接用二进制流上传分块，完全跳过FileReader转base64的步骤：把slice生成的Blob对象直接放入FormData，由浏览器以原生二进制的形式传输，不会在内存里生成大体积的base64字符串，直接砍掉33%的内存膨胀和长期驻留问题。

2. 停止全局复用FileReader实例 #

• 完全弃用这套FileReader转字符串的上传链路，只有需要预览文件缩略图这类必须转base64的场景才使用FileReader，上传链路全程不经过FileReader的大字符串转换。
• 确实需要使用FileReader的场景，要在读取完成、上传结束后，主动把reader实例和关联的result引用置为null，让垃圾回收可以及时释放内存。

3. 替换jQuery ajax为原生请求 #

• 原生fetch/XMLHttpRequest上传时，不会对二进制数据做额外的字符串序列化和拷贝，相比jQuery ajax可以减少近50%的临时内存占用。
• 利用原生的上传进度事件准确统计进度值，替代原代码里错误的进度计算逻辑。

4. 优化重试逻辑 #

• 触发分块重试时，不要重复调用FileReader读取逻辑，Blob对象本身已经存在内存中，直接把当前分块重新放入FormData发起上传即可，不需要重复读取、转换生成新的大体积字符串。
• 增加简单的重试间隔，避免瞬间连续触发多次请求造成内存峰值。

5. 内存兜底优化 #

• 把单块大小控制在4MB-8MB区间，不要设置过大的单块体积，避免单次读取的Blob占用过高的临时内存。
• 不要在上传链路的闭包里保存任何分块的副本数据，只维护当前上传分块的引用，分块上传完成后立刻释放引用。

const CHUNK_SIZE = 8 * 1024 * 1024; // 8MB单块大小
let uploadedOffset = 0;
let retryCount = 0;

async function uploadChunk(currentBlob) {
  // 直接用FormData装载二进制Blob，全程不转base64
  const formData = new FormData();
  formData.append('container', container);
  formData.append('blob', BlobName);
  formData.append('chunk', currentBlob);
  formData.append('id', id);

  try {
    const res = await fetch(uploadPath, {
      method: 'POST',
      body: formData,
      signal: AbortSignal.timeout(30000)
    });
    const result = await res.json();
    if (result.success === 'yes') {
      uploadedOffset += currentBlob.size;
      retryCount = 0; // 上传成功重置重试计数
      if (uploadedOffset < total) {
        // 直接切下一块Blob，不需要FileReader转换
        const nextBlob = file.slice(uploadedOffset, Math.min(uploadedOffset + CHUNK_SIZE, total));
        await uploadChunk(nextBlob);
      } else {
        // 全量上传完成逻辑
      }
    } else {
      if (retryCount++ > 3) {
        // 超过重试次数的错误处理
        return;
      }
      // 重试直接复用当前Blob，不做重复读取
      await uploadChunk(currentBlob);
    }
  } catch (err) {
    if (retryCount++ > 3) {
      // 请求失败的错误处理
      return;
    }
    await uploadChunk(currentBlob);
  }
}

// 启动上传流程
uploadChunk(file.slice(0, CHUNK_SIZE));

这套修复逻辑下，浏览器内存会稳定维持在单块大小的2-3倍区间，不会随着上传进度推进持续攀升，哪怕上传几十GB的大文件也不会触发内存超限报错。

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