大文件上传

我们来系统且深入地探讨一下JavaScript大文件上传的处理方案。我会从问题的本质出发，详细讲解核心原理、实现步骤、关键代码，并分析各种方案的优劣，最后给出我的建议。

---

一、问题的本质：为什么不能直接上传大文件？

在开始讨论解决方案之前，我们必须先理解问题的根源。一个看似简单的HTTP POST请求，为什么在文件变大后就变得不可靠？

1. HTTP连接的脆弱性：标准的HTTP上传是一个单一、长时程的请求。整个文件数据都在一个请求体中发送。如果用户的网络发生任何抖动（比如从Wi-Fi切换到4G、进入隧道、网络临时中断），这个长连接就会断开，导致整个上传过程失败。用户除了从头开始，别无选择。

2. 服务器限制：几乎所有的Web服务器（Nginx, Apache, Tomcat等）和后端应用框架（PHP, Node.js, Spring Boot等）都会配置一个请求体大小的上限（如Nginx的client_max_body_size，PHP的post_max_size）。这个限制是为了防止恶意攻击或服务器内存被单个巨大请求耗尽。任何超过此限制的上传都会被服务器直接拒绝，通常返回413 Request Entity Too Large错误。

3. 超时限制：浏览器和服务器都有连接超时时间。一个几GB的文件，在网速较慢的情况下可能需要数十分钟甚至几小时才能上传完毕。这个时间很可能超过了默认的超时设置，导致连接被强制关闭。

4. 糟糕的用户体验：

   • 无明确进度：浏览器原生的进度条只能显示整个请求的发送百分比，无法提供更精细的控制和展示。

   • 无法暂停/恢复：一旦开始，就不能暂停。一旦失败，就得重来。

   • 浏览器假死：在处理非常大的文件（例如计算MD5）时，如果处理不当，可能会长时间阻塞UI线程，导致浏览器页面卡顿甚至假死。

因此，直接上传大文件在现实世界中是不可行的。

二、核心解决方案：分片上传 (Chunking)

既然整个上传不可行，那么核心思想就是化整为零：将一个大文件在前端（浏览器）分割成多个小的数据块（Chunks），然后一块一块地上传。当所有小块都成功上传到服务器后，再由服务器将这些小块按照正确的顺序合并成原始文件。

这个方案完美地解决了上述所有问题：

• 可靠性：每个小块的上传都是一个独立的HTTP请求。即使某个请求失败，也只需要重新上传那一小块，而不需要重传整个文件。

• 绕过限制：每个小块的大小可以被精确控制（例如2MB），远低于服务器的请求体大小限制。

• 可控性：可以轻松实现暂停、恢复（断点续传）等高级功能。

• 优秀的用户体验：可以精确计算并展示总上传进度，甚至可以展示每个分片的上传状态。

• 并发上传：可以同时上传多个分片，利用多线程进一步提升上传速度。

---

三、分片上传的详细实现步骤

下面我们来分解整个流程，包括前端和后端的关键任务。

阶段一：前端处理

1. 选择文件

首先，需要一个<input type="file">元素让用户选择文件。

HTML

<input type="file" id="fileUploader">

2. 文件分片 (Slicing)

当用户选择了文件后，我们通过JavaScript获取到File对象。File对象是Blob的子类，它有一个非常重要的方法：slice(start, end)。这个方法可以从原始文件中“切”出一块数据，而不会消耗大量内存，因为它返回的是对源文件数据的引用。

JavaScript

const fileInput = document.getElementById('fileUploader');
fileInput.addEventListener('change', (e) => {
    const file = e.target.files[0];
    if (!file) return;

    const CHUNK_SIZE = 2 * 1024 * 1024; // 定义切片大小，这里是 2MB
    const chunks = [];
    let start = 0;

    while (start < file.size) {
        chunks.push(file.slice(start, start + CHUNK_SIZE));
        start += CHUNK_SIZE;
    }
    // `chunks` 数组现在包含了所有的文件切片
    // 下一步就是处理这些切片
});

3. 计算文件唯一标识 (Hash)

这是实现秒传和断点续传的基石。我们需要一个能唯一代表这个文件的ID。最常用的方法是计算文件的MD5或SHA系列哈希值。

挑战：直接对一个几GB的文件计算哈希会阻塞UI线程，导致页面卡死。

解决方案：

• Web Workers：将哈希计算任务放到一个后台线程中执行，避免阻塞主线程。

• 增量哈希：利用FileReader逐块读取文件内容，并增量地更新哈希值。这样内存占用小，且可以与Web Worker结合。

我们可以使用 spark-md5 这样的库来简化这个过程。

JavaScript

// 伪代码，展示使用 Web Worker 计算哈希的思路
// main.js
const worker = new Worker('hash-worker.js');
worker.postMessage({ file: file }); // 将文件传递给 worker
worker.onmessage = (e) => {
    const { hash } = e.data;
    console.log(`文件Hash计算完成: ${hash}`);
    // 拿到 hash 后，开始执行上传逻辑
    uploadChunks(chunks, hash);
};

// hash-worker.js
importScripts('spark-md5.min.js'); // 引入 spark-md5

self.onmessage = (e) => {
    const { file } = e.data;
    const spark = new SparkMD5.ArrayBuffer();
    const reader = new FileReader();

    reader.onload = (event) => {
        spark.append(event.target.result);
        self.postMessage({ hash: spark.end() });
        self.close();
    };

    reader.onerror = () => {
        self.postMessage({ error: '文件读取失败' });
    };

    reader.readAsArrayBuffer(file);
};

优化：对于超大文件，全量计算哈希可能依然耗时。一种优化策略是抽样哈希：只取文件的头、中、尾等部分数据进行哈希，这可以极快地完成，但会牺牲唯一性的绝对保证，适用于对唯一性要求不那么极致的场景。对于绝大多数需要精确秒传的场景，还是建议计算全文件哈希。

4. 上传切片

拿到文件Hash和切片数组后，我们就可以开始上传了。通常我们会使用FormData来构建每个切片的请求体。

每个请求都需要携带足够的信息，以便后端识别：

• 文件切片数据 (chunk)

• 文件唯一标识 (fileHash)

• 当前切片的索引/序号 (chunkIndex)

为了提升速度，我们可以并发上传多个切片，而不是一个接一个地串行上传。可以使用Promise.all或自己实现一个并发池来控制并发数量，避免一次性发送过多请求导致浏览器或服务器卡顿。

JavaScript

async function uploadChunks(chunks, fileHash) {
    const requests = chunks.map((chunk, index) => {
        const formData = new FormData();
        formData.append('chunk', chunk);
        formData.append('hash', fileHash);
        formData.append('index', index);

        return fetch('/upload-chunk', {
            method: 'POST',
            body: formData
        });
    });

    // 控制并发，例如一次最多上传 4 个
    const concurrency = 4;
    let pool = [];
    for (const request of requests) {
        const promise = request;
        pool.push(promise);
        
        promise.then(() => {
            // 从池中移除已完成的请求
            pool.splice(pool.indexOf(promise), 1);
        });

        if (pool.length >= concurrency) {
            // 等待池中任意一个请求完成
            await Promise.race(pool);
        }
    }
    
    // 等待所有剩余的请求完成
    await Promise.all(requests);

    // 所有切片上传完成后，通知服务器合并
    await notifyServerToMerge(fileHash, chunks.length);
}

5. 发送合并请求

所有切片都成功上传后，前端需要发送一个最终请求，通知后端：“关于fileHash这个文件的所有切片都已上传完毕，你可以开始合并了。”

JavaScript

async function notifyServerToMerge(fileHash, totalChunks) {
    await fetch('/merge-chunks', {
        method: 'POST',
        headers: {
            'Content-Type': 'application/json'
        },
        body: JSON.stringify({
            hash: fileHash,
            totalChunks: totalChunks
        })
    });
    console.log("文件上传成功！");
}

---

阶段二：后端处理

后端的技术栈可以是 Node.js, Java, Go, PHP 等任意语言，逻辑是相通的。这里以 Node.js + Express 框架为例。

1. 接收并存储切片

服务器需要一个接口（例如 /upload-chunk）来接收前端上传的切片。

• 创建临时目录：当第一个属于某文件（由fileHash标识）的切片到达时，以fileHash为名创建一个临时目录，用于存放该文件的所有切片。

• 存储切片：将接收到的切片文件以其索引（chunkIndex）为名，存入上述临时目录。例如：temp_uploads/file_hash_xyz/0, temp_uploads/file_hash_xyz/1, ...

JavaScript

const express = require('express');
const multer = require('multer');
const fs = require('fs-extra'); // fs-extra 提供了更多便利的文件操作方法
const path = require('path');

const app = express();
const UPLOAD_DIR = path.resolve(__dirname, 'temp_uploads');

const upload = multer({ dest: 'temp_uploads/' });

app.post('/upload-chunk', upload.single('chunk'), (req, res) => {
    const { hash, index } = req.body;
    const chunk = req.file;

    const chunkDir = path.resolve(UPLOAD_DIR, hash);
    if (!fs.existsSync(chunkDir)) {
        fs.mkdirsSync(chunkDir);
    }
    // 将临时文件移动到以索引命名的位置
    fs.renameSync(chunk.path, path.resolve(chunkDir, index.toString()));
    
    res.status(200).send('Chunk uploaded');
});

2. 合并切片

当接收到前端的合并请求时（例如 /merge-chunks），服务器执行以下操作：

• 读取临时目录：根据fileHash找到对应的临时目录。

• 排序切片：读取目录下的所有切片文件名，并按照数字大小（即切片索引）进行排序，确保顺序正确。

• 创建可写流：创建一个最终文件的可写流。

• 合并写入：依次读取每个排好序的切片文件，将其内容通过管道（pipe）或追加写入的方式写入最终文件。

• 清理：合并成功后，删除临时的切片目录。

JavaScript

app.post('/merge-chunks', express.json(), async (req, res) => {
    const { hash, totalChunks } = req.body;
    const chunkDir = path.resolve(UPLOAD_DIR, hash);
    const finalFilePath = path.resolve(__dirname, 'uploads', `${hash}.mp4`); // 假设是mp4

    try {
        const chunks = await fs.readdir(chunkDir);
        // 确保所有切片都已上传
        if (chunks.length !== totalChunks) {
            return res.status(400).send('Chunks missing');
        }

        // 按索引排序
        chunks.sort((a, b) => a - b);
        
        // 创建最终文件
        const writeStream = fs.createWriteStream(finalFilePath);

        for (const chunkIndex of chunks) {
            const chunkPath = path.resolve(chunkDir, chunkIndex);
            const readStream = fs.createReadStream(chunkPath);
            await new Promise((resolve, reject) => {
                readStream.pipe(writeStream, { end: false });
                readStream.on('end', resolve);
                readStream.on('error', reject);
            });
            // 删除已合并的切片
            fs.unlinkSync(chunkPath); 
        }

        writeStream.end();
        // 删除临时目录
        fs.rmdirSync(chunkDir); 

        res.status(200).send('File merged successfully');
    } catch (error) {
        res.status(500).send('Error merging chunks');
    }
});

---

四、核心进阶功能：断点续传与秒传

基于以上架构，实现这两个高级功能就变得水到渠成。

1. 断点续传 (Resumable Uploads)

在前端开始上传之前（计算完Hash后），先向服务器发送一个“验证”请求。

• 前端：GET /verify-upload?hash=file_hash_xyz

• 后端：

  1. 检查是否存在最终文件（uploads/file_hash_xyz.mp4）。如果存在，直接返回“秒传成功”。

  2. 如果最终文件不存在，则检查是否存在临时切片目录（temp_uploads/file_hash_xyz）。

  3. 如果存在，则读取该目录下已有的切片索引列表，并将其返回给前端。例如 {"uploadedChunks": ["0", "1", "3"]}。

  4. 如果都不存在，返回一个空列表。

• 前端：接收到已上传的切片列表后，在uploadChunks函数中，跳过这些已上传的切片，只上传剩余的部分。

2. 秒传 (Instant Upload)

秒传是断点续传验证过程中的一种特殊情况。当后端在验证请求中发现最终合并好的文件已经存在时，就意味着服务器已经拥有了这个一模一样的文件。此时，后端可以直接返回一个成功的响应，前端则可以跳过所有的上传步骤，直接提示用户“秒传成功”。这对于公共资源库或多人协作平台极其有用。

---

五、方案选择与总结

1. 原生实现 vs. 使用成熟的库

• 原生实现（从零开始写）

  • 优点：完全掌控所有细节，可以进行深度定制和优化，技术上能学到很多。

  • 缺点：非常复杂，需要处理大量边界情况，如网络重试、并发控制、浏览器兼容性、后端原子操作等，开发周期长，容易出错。

  • 适用场景：学习目的、有特定超高性能或定制化需求、有充足的开发资源。

• 使用成熟的库

  • 前端：Uppy, Plupload, 或者集成在UI框架中的上传组件（如 Element Plus 的 el-upload, Ant Design 的 Upload），它们通常都内置了分片、重试、断点续传等功能。

  • 后端：后端逻辑相对固定，但也可以找到一些辅助库来简化文件I/O和合并操作。

  • 优点：开箱即用，稳定可靠，经过了大量生产环境的检验，极大缩短开发时间。

  • 缺点：灵活性受限于库的API，可能需要花时间学习其配置和用法。

我的建议：

对于绝大多数的商业项目和生产环境，我强烈建议使用一个成熟、维护良好的第三方库，例如 Uppy。它为你处理了几乎所有你能想到的复杂情况，让你能专注于业务逻辑。从零开始构建一个鲁棒的大文件上传系统是一项巨大的工程。

如果你是为了深入学习，或者你的需求非常特殊，库无法满足，那么可以考虑原生实现。但即便如此，也应该先去阅读优秀库的源码，借鉴它们的实现思路。

总结一下，处理JS大文件上传的最佳实践路径是：

1. 核心思想：采用文件分片。

2. 关键技术：前端使用 File.slice() 进行切片，使用 Web Worker + spark-md5 异步计算文件 Hash。

3. 上传过程：通过Promise和并发控制，将携带 Hash 和索引的切片并发上传至后端。

4. 后端处理：接收切片并存入以 Hash 命名的临时文件夹，最后根据前端的合并请求，将所有切片排序合并成最终文件。

5. 高级优化：在上传前增加验证接口，通过查询后端是否已存在部分切片或完整文件，实现断点续传和秒传功能。

6. 方案抉择：在生产环境中，优先选择成熟的第三方库。

上传中途取消上传如何处理

这是一个非常好的问题，也是大文件上传流程中必须处理的关键环节。当用户中途取消上传时，前端和后端需要协同工作，以确保系统状态的一致性和资源的有效管理。

我们来详细拆解一下会发生什么，以及应该如何处理。

---

一、会发生什么？

当用户点击“取消”按钮时，如果不做任何处理，情况会是这样：

1. 前端（浏览器）：

   • 已经发出去的HTTP请求（正在上传的切片）会继续尝试完成。

   • 尚未开始的切片请求可能依然会按计划被发送。

   • 从用户的角度看，他点击了取消，但网络活动可能仍在后台进行，这不符合预期。

2. 后端（服务器）：

   • 服务器不知道前端已经“放弃”了这次上传。它会继续接收已经发出的切片，并将其保存在临时目录中。

   • 由于前端最终不会发送“合并切片”的请求，这些已经上传的、不完整的切片将永远留在服务器的临时文件夹里，成为**“孤儿文件” (Orphaned Files)**。

   • 日积月累，这些孤儿文件会占用大量的磁盘空间，造成资源浪费。

因此，一个健壮的取消功能是必不可少的。

---

二、如何正确处理取消操作

正确的处理分为前端和后端两部分。

1. 前端处理：立即中止所有相关请求

前端是取消操作的发起方，必须做到“令行禁止”。

核心任务： 终止所有正在进行和将要进行的上传请求。

现代最佳实践：使用 AbortController

AbortController 是浏览器原生提供的标准API，专门用于中止一个或多个Web请求。

实现步骤：

1. 创建 AbortController 实例：在开始上传任务之前，创建一个控制器实例。

   JavaScript

   const controller = new AbortController();
   

2. 将 signal 关联到请求：在发送每一个切片请求时，将控制器的 signal 对象传递给 fetch 的配置项。

   JavaScript

   // 在你的 uploadChunks 函数内部
   const requests = chunks.map((chunk, index) => {
       const formData = new FormData();
       // ... formData.append(...)
   
       return fetch('/upload-chunk', {
           method: 'POST',
           body: formData,
           signal: controller.signal // 关键：将 signal 关联到请求
       });
   });
   

3. 实现取消按钮的逻辑：当用户点击取消按钮时，调用控制器的 abort() 方法。

   JavaScript

   const cancelButton = document.getElementById('cancelButton');
   cancelButton.addEventListener('click', () => {
       controller.abort(); // 发出中止信号
       console.log("上传已取消");
       // 这里可以更新UI，例如隐藏进度条，显示“已取消”状态
   });
   

controller.abort() 会发生什么？

• 所有与该 signal 关联的、正在进行中的 fetch 请求会立即被浏览器中止，并抛出一个名为 AbortError 的异常。你需要用 try...catch 来捕获这个错误，以避免它在控制台报错。

• 所有尚未开始的请求将不会被发送。

• 这是一种非常高效和干净的方式，可以立即停止所有相关的网络活动。

（可选）通知后端取消

在调用 controller.abort() 之后，前端可以额外向后端发送一个“取消通知”请求。

JavaScript

// 在取消按钮的点击事件中
cancelButton.addEventListener('click', () => {
    controller.abort();
    
    // 可选：明确通知服务器删除临时文件
    fetch(`/cancel-upload?hash=${fileHash}`, { method: 'POST' });
});

这个请求的目的是让服务器可以立即清理临时文件，而不是等待后续的自动清理机制。但这并非绝对必要，因为后端必须有自己的保障机制。

2. 后端处理：清理孤儿切片

后端的首要任务是防止磁盘被孤儿文件占满。不能完全依赖前端的“取消通知”，因为这个通知本身也可能因为网络问题而失败。

核心任务： 建立一个可靠的垃圾回收机制。

最佳实践：定时清理任务 (Cron Job)

这是最常用、最可靠的方案。

1. 原理：编写一个后台脚本，该脚本会定期（例如每天凌晨2点）扫描存放切片的临时目录（例如 temp_uploads）。

2. 逻辑：

   • 遍历临时目录下的每一个以文件Hash命名的子目录。

   • 检查每个子目录的最后修改时间。

   • 如果某个目录的最后修改时间距离现在已经超过了一个设定的阈值（例如24小时或48小时），就认为这是一次被废弃的上传（无论是用户主动取消、浏览器崩溃还是网络中断导致的）。

   • 删除这个过期的临时目录及其中的所有切片文件。

为什么这个方案好？

• 可靠：它不依赖任何前端请求，无论上传因何种原因中断，它都能最终清理掉垃圾文件。

• 容错：它给了用户足够的时间来“续传”。例如，用户网络断了1小时后恢复，只要清理周期是24小时，他仍然可以找到之前的切片并继续上传。

实现示例 (Node.js + node-cron):

JavaScript

const cron = require('node-cron');
const fs = require('fs-extra');
const path = require('path');

const UPLOAD_DIR = path.resolve(__dirname, 'temp_uploads');
const EXPIRATION_TIME = 24 * 60 * 60 * 1000; // 24小时

// 每天凌晨2点执行
cron.schedule('0 2 * * *', async () => {
    console.log('开始执行临时文件清理任务...');
    const files = await fs.readdir(UPLOAD_DIR);
    
    for (const fileHash of files) {
        const dirPath = path.resolve(UPLOAD_DIR, fileHash);
        const stats = await fs.stat(dirPath);
        
        if (Date.now() - stats.mtime.getTime() > EXPIRATION_TIME) {
            console.log(`目录 ${fileHash} 已过期，正在删除...`);
            await fs.remove(dirPath); // fs-extra 的 remove 可以直接删除目录和内容
        }
    }
    console.log('清理任务完成。');
});

---

总结：取消上传的最佳实践流程

1. 用户点击取消。

2. 前端立即调用 AbortController.abort()，中止所有在途和待处理的切片上传请求。UI更新为“已取消”。

3. **前端（可选但推荐）**向后端发送一个 POST /cancel-upload 请求，通知服务器立即清理。

4. 后端接收到 POST /cancel-upload 请求后，立即删除对应的临时切片目录。

5. 后端（必须）运行一个定时的Cron Job，每天自动清理所有超过预设时限（如24小时）未完成合并的临时切片目录，作为最终的保障机制。

通过这套组合拳，无论用户是主动取消，还是因为意外情况中断，系统都能优雅地处理，既保证了良好的用户体验，又维护了服务器资源的健康。