从HTTP协议到Node.js实现：构建健壮的断点续传文件上传服务

1. 项目概述：为什么“断点续传”是每个开发者都该掌握的核心技能

“文件传一半，网络断了，又得从头再来”——这种体验，相信每个人都经历过。无论是下载一个几GB的游戏安装包，还是上传一份重要的项目备份，网络的不稳定性和传输中断的风险始终存在。而“断点续传”技术，就是专门为了解决这个痛点而生的。它允许你在传输中断后，从上次中断的地方继续传输，而不是重头开始，这极大地提升了用户体验和传输效率，尤其是在大文件、弱网络或移动场景下。

从技术角度看，断点续传绝不仅仅是客户端或服务器单方面的事情，它是一套涉及前后端协议、状态管理、文件操作和错误处理的完整工程实践。对于开发者而言，理解并实现一个健壮的断点续传功能，是检验其网络编程、文件处理和系统设计能力的绝佳试金石。它背后蕴含的“状态恢复”、“幂等操作”、“并发控制”等思想，在分布式系统、数据同步等更广阔的领域同样适用。

因此，今天我们不谈空泛的概念，直接深入骨髓，从协议原理到代码实操，完整地拆解如何从零构建一个支持断点续传的文件上传服务。我会以一个典型的HTTP文件上传场景为例，分享我在多个项目中打磨出的实现方案、踩过的坑以及那些教科书上不会写的优化技巧。无论你是前端、后端还是全栈开发者，掌握这套方法，都能让你在处理文件传输相关需求时更加游刃有余。

2. 核心原理与协议基础：HTTP范围请求（Range Requests）

实现断点续传，其基石是HTTP协议中的“范围请求”（Range Requests）机制。这是HTTP/1.1标准（RFC 7233）中定义的一个功能，它允许客户端只请求资源的一部分。

2.1 范围请求的工作机制

整个过程可以概括为“一问一答”加“续传”。假设我们要下载或上传一个文件。

首次请求或续传询问（客户端 -> 服务器）： 客户端通过在HTTP请求头中携带Range字段，向服务器声明它需要文件的哪一部分。格式是Range: bytes=start-end。例如：

• Range: bytes=0-1023表示请求前1024个字节。
• Range: bytes=2048-表示请求从第2048字节开始到文件末尾的所有内容。
• Range: bytes=500-999, 1500-1999表示请求多个不连续的范围（较少用于简单续传）。

对于上传场景的续传，机制类似但通常需要自定义实现，因为标准HTTP POST/PUT并不原生支持Range头用于上传。常见的做法是，客户端先发送一个HEAD请求或带特定参数的GET请求，询问服务器“这个文件我已经传了多少了？”，服务器返回已接收的字节数（例如通过Content-Range或自定义响应头）。然后客户端在后续的POST/PUT请求中，通过请求头（如Content-Range: bytes start-end/total）或请求体分块的方式，告知服务器本次传输的是文件的哪个片段。

服务器响应（服务器 -> 客户端）： 如果服务器支持范围请求，对于有效的范围请求，它会返回状态码206 Partial Content，而不是常见的200 OK。同时，响应头中会包含：

• Content-Range: 告诉客户端返回的内容在完整资源中的位置，格式为bytes start-end/total。例如Content-Range: bytes 2048-4095/10240。
• Content-Length: 本次响应返回的片段长度（例如2048），而不是整个文件的大小。

如果请求的范围无效（例如超出文件大小），服务器会返回416 Range Not Satisfiable状态码。

2.2 断点续传的关键状态管理

理解了协议，接下来最关键的是状态管理。续传的前提是“记住断点”。这需要解决几个问题：

1. 断点信息存哪里？不能只存在于内存中，否则服务重启就全忘了。必须持久化存储。通常有两种思路：

   • 服务端记录：为每个上传任务创建一个唯一标识（如UUID），在服务器端（数据库或Redis）记录该任务已成功接收的字节范围。客户端续传时携带任务ID查询进度。
   • 客户端记录：客户端本地（如浏览器IndexedDB、本地文件）记录每个文件的已上传字节数。续传时直接告诉服务器“我从第N字节开始传”。这种方式更简单，但可靠性稍差（客户端清理缓存会导致记录丢失）。

2. 文件如何拼接？服务器收到文件片段后，不能简单覆盖，必须准确地写入到完整文件的对应位置。这就要求服务器端具备随机写入文件的能力。在编程中，我们使用文件的“偏移量”（offset）来定位。例如，使用fs.createWriteStream时指定{ start: offset }选项，或在write系统调用中指定偏移量。

3. 如何保证一致性？网络传输可能出错，服务器写入也可能失败。我们需要确保状态（已接收字节数）与文件实际内容严格一致。通常采用“先写文件，成功后更新状态”的顺序，并且更新状态的操作最好是原子的。如果更新状态失败，宁可让客户端重传该片段，也不能让状态领先于实际数据，否则会导致文件损坏。

注意：对于下载场景，HTTP协议原生支持良好，浏览器和标准HTTP库（如curl、requests）会自动处理Range头和206响应，实现断点续传。我们的挑战主要集中在上传场景的实现上。

3. 服务端架构设计与核心实现

我们将构建一个基于Node.js（使用Koa框架）的简单文件上传服务端，它支持创建上传任务、分片上传、合并文件以及查询上传进度。

3.1 项目结构与依赖

首先初始化项目并安装必要依赖。

mkdir breakpoint-upload-server && cd breakpoint-upload-server npm init -y npm install koa koa-router koa-body koa-static uuid

• koa,koa-router: Web框架和路由。
• koa-body: 用于解析请求体，特别是支持文件上传的multipart/form-data格式。
• koa-static: 静态文件服务，用于测试时提供前端页面。
• uuid: 生成唯一的上传任务ID。

项目目录结构规划如下：

breakpoint-upload-server/ ├── server.js # 主入口文件 ├── uploads/ # 上传文件存储目录 │ └── temp/ # 分片临时存储目录 ├── taskMap.json # 上传任务状态存储文件（简化版，生产环境用DB） └── public/ # 静态文件目录（前端测试页） └── index.html

3.2 核心数据结构与状态持久化

为了简化，我们用一个JSON文件来模拟数据库，存储上传任务的状态。在生产环境中，应替换为Redis或关系型数据库。

taskMap.json结构示例：

{ "550e8400-e29b-41d4-a716-446655440000": { "fileName": "big_video.mp4", "fileSize": 104857600, "totalChunks": 100, "uploadedChunks": [0, 1, 2, 15, 16], // 已成功上传的分片索引 "status": "uploading", // uploading, merging, completed, failed "createTime": "2023-10-27T08:00:00.000Z" } }

• uploadedChunks数组记录了哪些分片已经上传成功。这是实现断点续传的核心状态。客户端可以查询这个数组，只上传缺失的分片。

3.3 核心API接口实现

在server.js中，我们实现四个核心接口：

3.3.1 初始化上传任务 (POST /api/initUpload)

客户端在开始上传前调用此接口，提供文件名和文件大小。服务端生成唯一任务ID，创建任务记录，并返回给客户端。

const Router = require('koa-router'); const router = new Router(); const { v4: uuidv4 } = require('uuid'); const fs = require('fs').promises; const path = require('path'); // 确保目录存在 const UPLOAD_DIR = path.resolve(__dirname, 'uploads'); const TEMP_DIR = path.join(UPLOAD_DIR, 'temp'); const TASK_MAP_PATH = path.join(__dirname, 'taskMap.json'); async function ensureDir(dir) { try { await fs.access(dir); } catch { await fs.mkdir(dir, { recursive: true }); } } // 读取/保存任务映射 let taskMap = {}; try { taskMap = require(TASK_MAP_PATH); } catch (e) { taskMap = {}; } async function saveTaskMap() { await fs.writeFile(TASK_MAP_PATH, JSON.stringify(taskMap, null, 2)); } router.post('/api/initUpload', async (ctx) => { const { fileName, fileSize, chunkSize = 1024 * 1024 } = ctx.request.body; // 默认分片1MB if (!fileName || !fileSize) { ctx.status = 400; ctx.body = { code: 400, msg: 'fileName and fileSize are required' }; return; } const taskId = uuidv4(); const totalChunks = Math.ceil(fileSize / chunkSize); taskMap[taskId] = { fileName, fileSize: Number(fileSize), chunkSize, totalChunks, uploadedChunks: [], // 初始为空数组 status: 'uploading', createTime: new Date().toISOString(), }; await saveTaskMap(); await ensureDir(path.join(TEMP_DIR, taskId)); // 为每个任务创建临时目录存放分片 ctx.body = { code: 200, data: { taskId, chunkSize, totalChunks }, msg: 'Upload task initialized successfully' }; });

3.3.2 上传文件分片 (POST /api/uploadChunk)

客户端将文件切分成多个分片（Blob），依次或并发调用此接口上传。关键点在于处理Content-Range头或通过表单字段传递分片信息。

我们采用更通用的表单字段方式：

const KoaBody = require('koa-body'); app.use(KoaBody({ multipart: true, formidable: { uploadDir: TEMP_DIR, // 临时存放目录 keepExtensions: true, maxFileSize: 200 * 1024 * 1024, // 200MB } })); router.post('/api/uploadChunk', async (ctx) => { const { taskId, chunkIndex, totalChunks } = ctx.request.body; const file = ctx.request.files?.chunk; // 表单中文件字段名为'chunk' if (!taskId || chunkIndex === undefined || !file) { ctx.status = 400; ctx.body = { code: 400, msg: 'Missing parameters' }; return; } const task = taskMap[taskId]; if (!task) { ctx.status = 404; ctx.body = { code: 404, msg: 'Upload task not found' }; return; } // 检查该分片是否已上传（实现续传的关键） if (task.uploadedChunks.includes(parseInt(chunkIndex))) { ctx.body = { code: 200, msg: `Chunk ${chunkIndex} already uploaded, skipped.` }; return; } // 将上传的临时文件移动到任务专属的临时目录，并以分片索引命名 const chunkFileName = `${chunkIndex}.part`; const chunkFilePath = path.join(TEMP_DIR, taskId, chunkFileName); try { await fs.rename(file.filepath, chunkFilePath); // 更新任务状态：记录该分片已上传 task.uploadedChunks.push(parseInt(chunkIndex)); task.uploadedChunks.sort((a, b) => a - b); // 保持顺序，便于检查 await saveTaskMap(); ctx.body = { code: 200, data: { uploadedChunks: task.uploadedChunks }, msg: `Chunk ${chunkIndex} uploaded successfully.` }; } catch (error) { ctx.status = 500; ctx.body = { code: 500, msg: `Failed to save chunk: ${error.message}` }; } });

3.3.3 查询上传进度 (GET /api/progress/:taskId)

客户端可以轮询或在上传每个分片后调用此接口，获取当前上传进度，用于更新进度条。

router.get('/api/progress/:taskId', async (ctx) => { const { taskId } = ctx.params; const task = taskMap[taskId]; if (!task) { ctx.status = 404; ctx.body = { code: 404, msg: 'Task not found' }; return; } const progress = task.uploadedChunks.length / task.totalChunks; ctx.body = { code: 200, data: { uploadedChunks: task.uploadedChunks, totalChunks: task.totalChunks, progress: Number(progress.toFixed(4)), status: task.status } }; });

3.3.4 合并文件分片 (POST /api/merge)

当所有分片都上传完成后，客户端调用此接口，触发服务端将所有分片按顺序合并成完整的文件。

router.post('/api/merge', async (ctx) => { const { taskId } = ctx.request.body; const task = taskMap[taskId]; if (!task) { ctx.status = 404; ctx.body = { code: 404, msg: 'Task not found' }; return; } // 检查是否所有分片都已上传 if (task.uploadedChunks.length !== task.totalChunks) { ctx.status = 400; ctx.body = { code: 400, msg: 'Not all chunks are uploaded yet.', uploaded: task.uploadedChunks.length, total: task.totalChunks }; return; } task.status = 'merging'; await saveTaskMap(); const finalFilePath = path.join(UPLOAD_DIR, task.fileName); const chunkDir = path.join(TEMP_DIR, taskId); const writeStream = fs.createWriteStream(finalFilePath); try { // 按分片索引顺序合并 for (let i = 0; i < task.totalChunks; i++) { const chunkPath = path.join(chunkDir, `${i}.part`); const buffer = await fs.readFile(chunkPath); writeStream.write(buffer); } writeStream.end(); // 等待流关闭，确保文件写入完成 await new Promise((resolve, reject) => { writeStream.on('finish', resolve); writeStream.on('error', reject); }); // 合并成功，更新状态，清理临时分片 task.status = 'completed'; await saveTaskMap(); await fs.rm(chunkDir, { recursive: true, force: true }); ctx.body = { code: 200, msg: 'File merged successfully.', data: { filePath: `/uploads/${task.fileName}` } }; } catch (error) { task.status = 'failed'; await saveTaskMap(); ctx.status = 500; ctx.body = { code: 500, msg: `Merge failed: ${error.message}` }; } });

4. 前端实现与优化策略

服务端准备好了，前端是触发和协调整个断点续传流程的指挥官。前端不仅要处理文件切片、并发控制、进度展示，还要实现续传逻辑。

4.1 文件切片与计算哈希

为了准确识别文件，防止同名不同内容的文件覆盖，并为续传提供更可靠的依据（仅靠文件名和大小可能不够），我们计算文件的哈希值（如MD5或SHA-256）作为唯一标识。

<!-- 简化版前端HTML (public/index.html) --> <input type="file" id="fileInput" /> <button onclick="handleUpload()">开始上传</button> <button onclick="pauseUpload()">暂停</button> <button onclick="resumeUpload()">继续</button> <div>进度：<span id="progress">0%</span></div> <script> // 使用SparkMD5库计算文件哈希，需提前引入 // <script src="https://cdnjs.cloudflare.com/ajax/libs/spark-md5/3.0.2/spark-md5.min.js"></script> async function calculateFileHash(file) { return new Promise((resolve) => { const chunkSize = 2 * 1024 * 1024; // 2MB一片计算哈希 const chunks = Math.ceil(file.size / chunkSize); const spark = new SparkMD5.ArrayBuffer(); const fileReader = new FileReader(); let currentChunk = 0; function loadNext() { const start = currentChunk * chunkSize; const end = start + chunkSize >= file.size ? file.size : start + chunkSize; fileReader.readAsArrayBuffer(file.slice(start, end)); } fileReader.onload = e => { spark.append(e.target.result); currentChunk++; if (currentChunk < chunks) { loadNext(); } else { const hash = spark.end(); resolve(hash); } }; fileReader.onerror = () => resolve(null); loadNext(); }); } </script>

4.2 实现带续传功能的上传管理器

前端需要维护一个上传任务的状态，包括任务ID、文件哈希、分片列表、已上传分片索引等。

class UploadManager { constructor(file) { this.file = file; this.taskId = null; this.fileHash = null; this.chunkSize = 1 * 1024 * 1024; // 1MB this.totalChunks = 0; this.chunkList = []; this.uploadedChunksSet = new Set(); // 记录已上传成功的分片索引 this.isPaused = false; this.concurrentLimit = 3; // 最大并发数 this.uploadingQueue = []; } async init() { // 1. 计算文件哈希 this.fileHash = await calculateFileHash(this.file); // 2. 初始化上传任务到服务端 const initResp = await fetch('/api/initUpload', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ fileName: this.file.name, fileSize: this.file.size, fileHash: this.fileHash, chunkSize: this.chunkSize }) }).then(r => r.json()); if (initResp.code !== 200) throw new Error(initResp.msg); this.taskId = initResp.data.taskId; this.totalChunks = initResp.data.totalChunks; // 3. 查询现有进度（实现续传的关键步骤） await this.fetchProgress(); } async fetchProgress() { const resp = await fetch(`/api/progress/${this.taskId}`).then(r => r.json()); if (resp.code === 200) { this.uploadedChunksSet = new Set(resp.data.uploadedChunks); updateProgressUI(resp.data.progress); // 更新UI } } async upload() { this.isPaused = false; // 创建所有分片的Promise，但只上传未完成的 const uploadPromises = []; for (let i = 0; i < this.totalChunks; i++) { if (this.uploadedChunksSet.has(i)) continue; // 跳过已上传的 uploadPromises.push(this.uploadChunk(i)); } // 控制并发上传 await this.runConcurrent(uploadPromises, this.concurrentLimit); // 所有分片上传完成后，触发合并 if (this.uploadedChunksSet.size === this.totalChunks) { await this.mergeFile(); } } async uploadChunk(index) { if (this.isPaused) return Promise.reject(new Error('Upload paused')); const start = index * this.chunkSize; const end = Math.min(start + this.chunkSize, this.file.size); const chunkBlob = this.file.slice(start, end); const formData = new FormData(); formData.append('taskId', this.taskId); formData.append('chunkIndex', index); formData.append('totalChunks', this.totalChunks); formData.append('chunk', chunkBlob, `chunk-${index}`); try { const resp = await fetch('/api/uploadChunk', { method: 'POST', body: formData }).then(r => r.json()); if (resp.code === 200) { this.uploadedChunksSet.add(index); await this.fetchProgress(); // 上传成功，更新进度 } else { throw new Error(resp.msg); } } catch (error) { console.error(`Upload chunk ${index} failed:`, error); // 可以加入重试逻辑 throw error; } } // 简单的并发控制函数 async runConcurrent(tasks, limit) { const results = []; const executing = []; for (const task of tasks) { const p = Promise.resolve().then(() => task()); results.push(p); const e = p.then(() => executing.splice(executing.indexOf(e), 1)); executing.push(e); if (executing.length >= limit) { await Promise.race(executing); } } return Promise.all(results); } async mergeFile() { const resp = await fetch('/api/merge', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ taskId: this.taskId }) }).then(r => r.json()); alert(resp.msg); } pause() { this.isPaused = true; } async resume() { await this.fetchProgress(); await this.upload(); } } // 使用示例 let uploader = null; async function handleUpload() { const fileInput = document.getElementById('fileInput'); if (!fileInput.files.length) return; const file = fileInput.files[0]; uploader = new UploadManager(file); try { await uploader.init(); await uploader.upload(); } catch (error) { console.error('Upload failed:', error); } } function pauseUpload() { if (uploader) uploader.pause(); } function resumeUpload() { if (uploader) uploader.resume(); } </script>

4.3 前端优化与体验提升

1. 并发控制与错误重试：如上代码所示，通过runConcurrent方法限制同时发起的HTTP请求数量，避免浏览器卡死或服务器压力过大。在uploadChunk方法中，可以包裹一个重试机制（例如最多重试3次），增强鲁棒性。
2. 进度计算：进度计算应基于已上传的数据量，而不是分片数量。因为最后一个分片可能很小。更准确的进度是：(sum(uploadedChunkSizes) / totalFileSize) * 100。我们在服务端返回的uploadedChunks数组基础上，前端可以自己计算。
3. 暂停/恢复与页面刷新持久化：当前的暂停只是停止了新请求的发出。更完善的暂停应该立即中止正在进行的请求（使用AbortController）。为了支持页面刷新后继续，需要将taskId和fileHash存储在localStorage中，页面加载时检查并恢复任务状态。
4. 秒传与极速上传：在initUpload时，将文件哈希发送到服务器。服务器可以检查是否已有相同哈希的文件存在。如果存在，直接返回“秒传”成功，无需实际上传。这需要服务端建立文件哈希到存储路径的映射。

5. 生产环境进阶考量与问题排查

将上述Demo部署到生产环境，还需要解决一系列工程化问题。

5.1 安全性加固

1. 文件校验：
   • 分片校验：服务端在保存每个分片后，可以计算其MD5并与客户端传来的校验和比对，防止网络传输错误或篡改。
   • 最终文件校验：合并完成后，计算完整文件的哈希，与客户端最初传来的fileHash比对，确保文件完整性。
2. 恶意攻击防护：
   • 大小限制：限制单个文件大小、总上传大小。
   • 频率限制：对/api/uploadChunk接口进行限流，防止DoS攻击。
   • 类型检查：检查文件扩展名和MIME类型，防止上传可执行文件等危险类型。注意，这不能作为唯一的安全措施。
3. 权限验证：所有API接口都应置于身份认证（如JWT）之后，确保只有授权用户才能上传。taskId应与用户ID关联，防止用户操作他人的上传任务。

5.2 性能与可扩展性

1. 状态存储：示例中使用JSON文件，仅适用于单机演示。生产环境必须使用外部存储：
   • Redis：存储taskMap的理想选择，读写速度快，支持过期时间，可以自动清理僵尸任务。
   • 数据库：如果需要持久化任务历史记录，可使用MySQL/PostgreSQL。将uploadedChunks数组可能需序列化存储或使用关联表。
2. 分片存储：将分片直接存储在服务器本地磁盘，在分布式环境下会有问题。应使用对象存储服务（如AWS S3、阿里云OSS、MinIO）。许多对象存储服务原生支持分片上传（Multipart Upload）和断点续传，我们的服务层可以是对其API的封装和状态管理。
3. 合并优化：对于超大文件，在内存中顺序读取-写入所有分片（for循环）可能效率低下且内存消耗大。应使用流（Stream）进行管道式合并。在Node.js中，可以用fs.createReadStream和fs.createWriteStream配合pipeline函数。

   const { pipeline } = require('stream/promises'); const writeStream = fs.createWriteStream(finalFilePath); for (let i = 0; i < totalChunks; i++) { const chunkPath = path.join(chunkDir, `${i}.part`); const readStream = fs.createReadStream(chunkPath); await pipeline(readStream, writeStream, { end: false }); // end: false 保持写流打开 } writeStream.end(); // 最后关闭写流

4. 清理僵尸任务：有些任务初始化后可能永远无法完成。需要有一个后台定时任务，清理超过一定时间（如24小时）仍处于uploading状态的任务，删除其临时分片文件，释放存储空间。

5.3 常见问题排查实录

在实际开发和运维中，我遇到过不少典型问题：

1. “分片丢失”或“合并后文件损坏”

   • 现象：进度显示100%，但合并后的文件无法打开或大小不对。
   • 排查：
     • 检查分片索引是否从0开始连续。前端切片逻辑的start和end计算是否正确。
     • 检查服务端保存分片时，文件名是否严格按照索引命名（如0.part,1.part），避免因并发导致覆盖。
     • 最关键的检查点：合并时，必须严格按照索引顺序写入。我们的for循环是顺序的，但如果改用并发合并，必须严格保证顺序。
     • 在合并前后，分别计算所有分片大小之和与最终文件大小，看是否相等。
   • 心得：在关键步骤（保存分片、更新状态、合并）加入详细的日志，记录分片索引、大小、哈希，是快速定位问题的利器。

2. “进度条回退”或“重复上传”

   • 现象：暂停后继续，或者刷新页面后，进度从某个值（如50%）又从头开始，或者客户端重复上传已传过的分片。
   • 排查：
     • 服务端状态未持久化：确保saveTaskMap()是原子操作且成功执行。在示例中，如果多个请求同时修改taskMap并保存，可能丢失更新。生产环境用Redis的HSET或数据库事务可以解决。
     • 客户端状态与服务器不同步：客户端在resume时，必须首先调用fetchProgress()从服务器拉取最新的uploadedChunks，而不是依赖自己内存中的旧状态。
     • 网络重试导致重复请求：前端上传分片时，如果网络超时但实际服务器已处理成功，客户端重试会导致分片重复上传。服务端的uploadedChunks.includes检查就是用来做幂等处理的，确保同一分片多次上传请求只有第一次生效。

3. “上传到一半卡住”

   • 现象：并发上传多个分片时，某个分片失败阻塞了整个队列。
   • 解决：
     • 如4.2节所示，实现良好的并发控制，并且每个分片的上传Promise应该是独立的，一个失败不应影响其他分片。可以使用Promise.allSettled来等待所有分片上传结束，然后收集失败的分片进行重试。
     • 设置合理的超时时间和重试机制。对于失败的分片，可以放入一个重试队列，延迟后重新上传。

4. “内存占用过高”

   • 现象：上传大文件或并发数设得过高时，服务器或浏览器内存飙升。
   • 解决：
     • 前端：使用File.slice创建Blob是廉价的，不会将整个文件读入内存。但并发数 (concurrentLimit) 不宜过高，一般3-5个即可。
     • 后端：使用koa-body或multer等中间件时，注意其临时文件处理。确保流式处理文件，避免将整个文件块缓冲到内存中。我们的示例中，formidable将文件先保存为临时文件，是流式处理的一种方式。

实现一个健壮的断点续传功能，就像打造一个精密的机械表，每个齿轮（状态管理、分片、合并、校验）都必须严丝合缝。从简单的Demo到生产可用的系统，中间隔着对网络不确定性、系统故障和恶意输入的深刻理解与防范。这套方案不仅适用于文件上传，其核心思想——将大任务分解、记录进度、支持从中断处恢复——可以迁移到任何需要处理长时间运行、可能中断任务的场景中，例如数据迁移、视频转码、批量处理等。