大文件处理前端

概述

在 Web 应用中上传大文件（如高清视频、设计稿压缩包、数据集文件等）是一项常见的工程挑战。传统表单上传受限于 HTTP 请求体大小限制、网络不稳定导致的传输中断、无进度反馈等问题，用户体验极差。针对这些痛点，前端开发中衍生出了分片上传、断点续传、秒传（文件去重）、进度追踪、并发控制等一系列技术方案。

本文将从实际工程出发，深入解析大文件上传的技术原理和实现细节，涵盖分片策略、哈希计算、并发控制、暂停/恢复机制，并结合前端 Demo 展示完整实现。

---

一、分片上传原理

1.1 为什么需要分片

大文件直接上传存在以下问题：

问题	说明
HTTP 请求大小限制	Nginx 默认 client_max_body_size 为 1MB，云网关通常限制 10-100MB
网络波动	上传过程中断需要从头重传，大文件重传成本极高
无进度反馈	整体上传无法获知传输进度，用户体验差
并发受限	单连接上传无法充分利用带宽

分片上传的核心思路是将大文件切割为若干小片段（Chunk），分多次请求上传到服务端，服务端接收完毕后再合并为完整文件。

1.2 File.slice 分割

浏览器提供了 File.slice(start, end) 方法，可以像数组一样对文件进行切片：

const CHUNK_SIZE = 5 * 1024 * 1024; // 5MB 每片

function createChunks(file) {
  const chunks = [];
  let start = 0;
  while (start < file.size) {
    const end = Math.min(start + CHUNK_SIZE, file.size);
    chunks.push(file.slice(start, end));
    start = end;
  }
  return chunks;
}

分片大小选择：过小（< 1MB）导致请求过多，网络开销大；过大（> 10MB）则失去分片意义。通常建议 2-5MB，需结合服务端限制和网络环境调整。

1.3 并发控制

分片上传时，同时发起所有分片请求可能导致客户端 OOM 或服务端过载。合理的做法是限制并发数：

async function uploadChunks(chunks, concurrency = 3) {
  const results = [];
  const queue = chunks.map((chunk, index) => ({ chunk, index }));
  
  async function worker() {
    while (queue.length > 0) {
      const { chunk, index } = queue.shift();
      const result = await uploadSingleChunk(chunk, index);
      results[index] = result;
      updateProgress(results);
    }
  }
  
  // 启动多个 Worker 并发处理
  const workers = Array.from({ length: concurrency }, () => worker());
  await Promise.all(workers);
  return results;
}

通过"生产者-消费者"模型，维护一个任务队列，多个 Worker 并发消费，既利用带宽又控制资源。

---

二、断点续传

2.1 续传原理

断点续传的核心是"记录已上传的分片，失败后只重传未完成的分片"。实现的关键在于：

1. 分片标识：每个分片需要唯一标识，通常使用 文件哈希 + 分片序号
2. 进度记录：将已上传的分片序号持久化到 localStorage 或 IndexedDB
3. 恢复逻辑：上传前查询已上传分片列表，跳过已完成的分片

2.2 进度持久化

前端使用 localStorage 保存上传进度：

function saveProgress(fileHash, uploadedChunks) {
  const key = `upload_${fileHash}`;
  localStorage.setItem(key, JSON.stringify(uploadedChunks));
}

function loadProgress(fileHash) {
  const key = `upload_${fileHash}`;
  const raw = localStorage.getItem(key);
  return raw ? JSON.parse(raw) : [];
}

注意事项：

• localStorage 有 5-10MB 存储限制，仅保存分片序号数组足够
• 上传完成后及时清理缓存，避免存储膨胀
• 考虑存储空间不足时降级处理

2.3 暂停与恢复

暂停/恢复是断点续传的用户交互体现：

• 暂停：中断所有正在进行的请求，记录当前已上传的分片
• 恢复：重新查询已上传分片列表，跳过已完成的分片重新开始上传

实现时需要注意：使用 AbortController 或 XMLHttpRequest.abort() 中断正在进行的请求，防止暂停后仍有分片上传。

---

三、文件哈希计算与秒传

3.1 哈希计算用途

文件哈希（通常是 MD5 或 SHA1）在大文件上传中有两个核心作用：

1. 文件去重（秒传）：服务端根据哈希判断文件是否已存在，若已存在则直接返回成功
2. 分片完整性校验：每个分片上传后校验哈希，确保传输过程中未损坏

3.2 前端哈希计算方案

在前端计算大文件哈希是一项计算密集型操作，推荐方案：

SparkMD5：最流行的前端 MD5 库，支持增量计算：

import SparkMD5 from 'spark-md5';

function calculateHash(file) {
  return new Promise((resolve) => {
    const spark = new SparkMD5.ArrayBuffer();
    const reader = new FileReader();
    const chunkSize = 2 * 1024 * 1024;
    let currentChunk = 0;
    const totalChunks = Math.ceil(file.size / chunkSize);

    reader.onload = (e) => {
      spark.append(e.target.result);
      currentChunk++;
      if (currentChunk < totalChunks) {
        loadNext();
      } else {
        resolve(spark.end());
      }
    };

    function loadNext() {
      const start = currentChunk * chunkSize;
      const end = Math.min(start + chunkSize, file.size);
      reader.readAsArrayBuffer(file.slice(start, end));
    }
    loadNext();
  });
}

Web Worker 优化：大文件哈希计算可能耗时数秒甚至数十秒，在 Worker 线程中执行避免阻塞 UI：

// main.js
const worker = new Worker('hash-worker.js');
worker.postMessage({ file });
worker.onmessage = (e) => {
  const hash = e.data;
  // 处理哈希结果
};

// hash-worker.js
self.importScripts('https://cdn.jsdelivr.net/npm/spark-md5@3.0.2/spark-md5.min.js');
self.onmessage = (e) => {
  const { file } = e.data;
  // ... 计算哈希
  self.postMessage(hash);
};

3.3 秒传流程

1. 客户端计算文件哈希
2. 请求服务端查询该哈希是否已存在
3. 若已存在，直接返回"上传成功"（秒传）
4. 若不存在，继续分片上传

---

四、上传进度管理

4.1 分片级进度

前端上传进度可以从两个维度追踪：

分片维度：单个分片的上传进度（通过 xhr.upload.onprogress 或 fetch 的 stream API）

function uploadWithProgress(chunk, index) {
  return new Promise((resolve, reject) => {
    const xhr = new XMLHttpRequest();
    xhr.upload.onprogress = (e) => {
      if (e.lengthComputable) {
        const percent = (e.loaded / e.total) * 100;
        updateChunkProgress(index, percent);
      }
    };
    xhr.onload = () => resolve(xhr.responseText);
    xhr.onerror = () => reject(new Error('Upload failed'));
    xhr.open('POST', '/api/upload/chunk');
    xhr.send(chunk);
  });
}

总体维度：已完成分片数 / 总分片数

总体进度 = (已完成分片数 / 总分片数) × 100%

4.2 上传速度估算

通过记录固定时间间隔内上传的数据量计算瞬时速度：

let lastBytes = 0;
let lastTime = Date.now();

setInterval(() => {
  const now = Date.now();
  const elapsed = (now - lastTime) / 1000; // 秒
  const bytesDelta = currentBytes - lastBytes;
  const speed = bytesDelta / elapsed; // bytes/s
  // 转换为 KB/s 或 MB/s 展示
  lastBytes = currentBytes;
  lastTime = now;
}, 500);

速度估算使用滑动窗口平均算法更为准确，避免瞬时波动造成的显示抖动。

4.3 视觉反馈设计

良好的进度展示应包含：

• 总体进度条：大进度条展示整体完成百分比
• 分片状态网格：每个分片独立展示（待上传/上传中/已完成/失败）
• 实时速度：KB/s 或 MB/s 实时显示
• 已用时间：格式化为 00:00 或 00:00:00
• 预计剩余时间：根据速度和剩余数据量估算

---

五、工程实践与异常处理

5.1 错误重试

网络环境复杂，分片上传失败是常态。健全的重试机制应包含：

• 自动重试：单分片失败后自动重试 3 次
• 指数退避：重试间隔逐步增加（1s、2s、4s...）
• 分片标记：失败分片标记为 error 状态，最终汇总展示

5.2 上传完成

所有分片上传完毕后，前端需要通知服务端合并文件：

async function finishUpload(fileHash, totalChunks) {
  const res = await fetch('/api/upload/merge', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ hash: fileHash, chunks: totalChunks })
  });
  return res.json();
}

5.3 上传历史

为提升用户体验，建议保存上传历史记录到 localStorage，包含：

• 文件名、大小、类型
• 上传时间
• 文件哈希
• 总片数

用户可以在历史列表中查看过往上传记录，了解文件传输的完整轨迹。

---

实战 Demo

以下是一个完整的大文件上传管理器 Demo。它模拟了文件拖拽选择、哈希计算、分片并发上传、进度追踪、暂停/继续、速度估算以及上传历史记录等功能，使用纯前端模拟无需后端支持。

总结

大文件上传不仅仅是"把文件传给服务器"，它融合了分片算法、并发控制、哈希计算、本地存储、Web Worker 线程等多方面的前端技术。一个健壮的大文件上传方案需要综合考虑分片大小、并发数、重试策略、进度反馈等多个维度的权衡。随着浏览器能力的增强（如 File System Access API、Streams API），未来大文件前端处理的体验将进一步提升。