傳：文件分片、hash計算與并發(fā)上傳實踐)
看到這個標題我想你大概是遇到了一個現(xiàn)實問題項目里要傳幾百MB甚至幾個G的文件結果每次傳到一半就斷要不就是頁面卡死、用戶關掉又重新從0%開始。這套基于JavaScript、Vue、Node.js寫出來的大文件斷點續(xù)傳DEMO就是為了解決這個痛點。我會用Vue 3配合File API里的slice方法做文件分片用spark-md5計算文件hash再用axios并發(fā)上傳分片最后寫一個不算復雜的Node.js服務端做分片存儲和合并。整個過程下來有Vue基礎的人照著敲一遍就能跑通也能理解斷點續(xù)傳背后的原理。1. 先把斷點續(xù)傳這件事想明白拆片、記錄、重組1.1 一次上傳為什么靠不住在開始寫DEMO之前先倒回去想一個問題為什么不能直接拿一個文件往后端丟不是不能而是現(xiàn)實世界里大文件直接傳輸?shù)捏w驗非常差。瀏覽器里的File對象本質上是一個Blob你把一個幾個GB的文件塞進FormData一個HTTP請求發(fā)出后整個請求體一直占著網絡連接服務器那邊如果用的是Express這類框架默認也會對整個請求做緩沖內存一下就繃緊。更關鍵的是傳輸中間只要有一點抖動TCP連接斷了整個請求就沒了瀏覽器不會因為文件太大就對你手下留情用戶體驗就是“卡在99%然后重來”。還有一個容易被忽略的問題很多網關和Web服務器對單次請求體都有硬性限制Nginx默認的client_max_body_size很小就算你配置了十幾GB也架不住中間機器超時回收。所以“把一個文件變成很多個小文件分別上傳”是繞開這些限制的最實用手段這也是斷點續(xù)傳方案的核心一個文件被切成N片每片都是一個獨立請求失敗了對單一片重試而不是對整個文件重試。1.2 斷點續(xù)傳和普通上傳到底差在哪普通上傳里文件的二進制流從頭傳到尾中間任何一個地方斷掉已經傳出去的字節(jié)就全部作廢。斷點續(xù)傳則圍繞“狀態(tài)”來做文章先記住這個文件的唯一身份再記住哪些分片已經上傳成功下次重新打開頁面或者點擊續(xù)傳時只需要從沒傳過的分片繼續(xù)已經傳過的分片直接跳過。這個“記住”的過程就是后端只認hash和分片序號hash是文件指紋分片序號是位置。把斷點續(xù)傳和完整上傳放在一起對比差異就非常明顯傳輸粒度完整上傳是單一數(shù)據流斷點續(xù)傳是一個個獨立分片。失敗成本完整上傳一旦失敗全部重來斷點續(xù)傳只需要重傳失敗的那幾片理想狀態(tài)下接近零成本?？蓵和Ｐ酝暾蟼鞑荒苤型緯和；謴蛿帱c續(xù)傳隨時可以暫停下次繼續(xù)。秒傳能力如果服務端已經保存過同樣hash的文件可以直接提示上傳完成根本不用再上傳。這些差異是斷點續(xù)傳被選來對付大文件的核心原因。1.3 整體方案選型為什么選Vue 3 Node.js嚴格說起來斷點續(xù)傳是前端工程和前后端契約共同完成的不涉及什么黑魔法。demo里我用的組合是Vue 3 axios spark-md5后端用Node.js Express multer主要是因為這套組合和你標題里的“JavaScript怎么編寫”完全在一個語言體系里前端JavaScript負責切片、算hash、并發(fā)控制后端JavaScript負責收分片、存狀態(tài)、合并文件前后端不需要切換技術?？雌饋砀槨ue 3的Composition API在管理上傳任務時比Vue 2的Options API直觀得多ref、computed這些響應式原語能把文件、hash、已上傳分片、進度這些狀態(tài)統(tǒng)一管理起來。demo里我不會引入太重量的UI庫直接用原生button和簡單的div滾動條因為斷點續(xù)傳的核心不在UI組件而在于分片、hash和狀態(tài)同步你以后接Element Plus還是Ant Design Vue都很容易。提示如果你在真實項目里用的是React、Angular或原生JS這套思路同樣成立因為真正核心的是File.slice、FormData和XHR/fetch這些瀏覽器標準API框架只是外層殼。2. 前端分片與指紋計算從代碼層面吃透2.1 用 Blob.slice 把大文件切成小塊文件分片最根本的API就是Blob.prototype.sliceFile繼承自Blob所以可以直接file.slice(start, end)拿到原文件的一部分。這個操作不是把文件物理切開而是生成一個新的Blob底層可能仍然引用原文件的內存區(qū)域所以性能很高不會因為切一下就把大文件整個復制一遍。以4MB為一片舉例分片邏輯如下const CHUNK_SIZE 4 * 1024 * 1024 function createFileChunks(file) { const chunks [] let start 0 while (start file.size) { const end Math.min(start CHUNK_SIZE, file.size) const chunk file.slice(start, end) chunks.push(chunk) start end } return chunks }這里有幾個細節(jié)要特別注意。第一最后一片的大小往往小于CHUNK_SIZE切片時end要用Math.min兜住文件大小否則會拿到一個空的Blob。第二每個分片必須帶上它在整個文件中的序號否則服務端合并時不知道先后順序這也就是后面接口里一直出現(xiàn)的index字段。第三切片時盡量讓每片大小保持一致這樣服務端合并、前端重試時邏輯都簡單。實際上分片大小不是一個固定的最佳值我見過很多人直接套一個“5MB”到處用。片越小請求數(shù)量越多服務端文件句柄和前端Promise對象都會壓滿片越大單請求傳輸時間越長斷點續(xù)傳的“續(xù)”就變得不精細。通常我建議從2MB到10MB之間取值公網環(huán)境取4MB左右比較平衡內網環(huán)境可以放大到10MB請求數(shù)量和恢復精度都兼顧了。2.2 用 spark-md5 算出文件唯一指紋分片之后遇到第一個問題怎么讓服務端知道“這兩個文件其實是同一個”最可靠的方案不是文件名因為同名文件內容可以完全不一樣也不是文件大小因為大小相同內容也可能不同而是給文件內容本身算一個摘要也就是hash。前端把整個文件的hash發(fā)給后端后端拿hash作為分片目錄名這樣同一個文件即使你改了文件名再傳也能直接續(xù)上。spark-md5是前端算文件hash最常用的庫它支持增量計算可以邊讀分片邊更新hash不用一口氣把整個文件讀進內存。核心代碼如下import SparkMD5 from spark-md5 async function calcFileHash(file) { const spark new SparkMD5.ArrayBuffer() let offset 0 while (offset file.size) { const chunk file.slice(offset, offset CHUNK_SIZE) const buffer await chunk.arrayBuffer() spark.append(buffer) offset CHUNK_SIZE } return spark.end() }這里值得說一下ArrayBuffer模式spark.append可以接收ArrayBuffer、binary string等對大文件來說用ArrayBuffer模式的性能更好因為瀏覽器底層可以直接給你二進制內存塊。每次循環(huán)只把當前這一片讀成buffer算完就釋放內存占用量被控制在一個分片大小內。如果文件達到了幾個GB這個計算過程可能要花幾十秒為了不阻塞界面真實項目最好放到Web Worker里跑demo階段為了少繞一圈直接放主線程后面我會專門講怎么處理卡UI的問題。有一點必須提前說清楚hash算出來的值只代表你本地看到的內容不代表傳輸過程中沒有損壞。真正要求嚴謹?shù)膱鼍胺斩嗽诤喜⑼瓿珊筮€要再算一次hash和前端提交的hash比對不一致就說明傳壞了。demo里我會在合并接口里做一次最簡單的數(shù)量校驗。2.3 分片上傳并發(fā)控制的實現(xiàn)思路分片準備好了hash也有了是不是直接把所有分片一次性全部發(fā)出去不行。幾百個分片同時發(fā)起請求瀏覽器連接數(shù)有限服務器也會被瞬間打掛進度條回升得又慢又不穩(wěn)定。正確做法是控制并發(fā)比如最多同時傳3到5片。并發(fā)控制寫起來一點都不難核心就是一個消費者隊列維護一個游標分給固定數(shù)量的worker去消費待上傳列表每個worker取到一片傳一片傳完繼續(xù)取下一下片直到全部消費完。我習慣寫成這樣async function uploadWithConcurrency(pendingList, poolLimit) { let cursor 0 const workers [] const runWorker async () { while (cursor pendingList.length) { const current cursor const item pendingList[current] await uploadChunk(item.chunk, item.index) } } const workerCount Math.min(poolLimit, pendingList.length) for (let i 0; i workerCount; i) { workers.push(runWorker()) } await Promise.all(workers) }這樣寫的好處是讓每個worker異步循環(huán)拉任務而不是先分配固定任務這樣慢的分片不會拖累其他worker。實際跑的時候你可以在uploadChunk里給每個分片附加index和hash并在成功后把index記錄進已上傳集合中。暫停功能的核心也是這個隊列暫停時用一個標志位讓worker的while循環(huán)直接退出并且取消掉正在進行的axios請求恢復時用當前已上傳集合過濾出還沒傳的分片重新建一個隊列跑起來。3. 服務端接口怎么設計才能支撐前端這套玩法3.1 約定三個核心接口check、upload、merge前端和后端的分工必須通過接口契約固定下來demo里我把它收成三個接口這也是大多數(shù)斷點續(xù)傳服務的最小集合接口方法核心參數(shù)職責/api/checkPOSThash查詢服務端已存在哪些分片序號/api/uploadPOSTfile、hash、index上傳單個分片/api/mergePOSThash、name、total通知服務端合并所有分片check接口的作用是“斷點查詢”。用戶打開頁面重新選擇一個文件前端算完hash后先問服務端這個文件傳過嗎傳到了第幾片服務端把已有分片的索引數(shù)組返回給前端前端過濾掉這些序號只傳剩下的。這個接口讓“續(xù)傳”真正成立不然每次重開頁面都不知道從哪里繼續(xù)。upload接口接收的就是某一個分片的二進制這里有個重要約定分片必須帶hash和index。hash決定它落到哪個目錄index決定它在合并時的位置。為了簡化設計后端按hash建目錄目錄里的文件名直接就是“index.part”查找已上傳分片就是讀取目錄下有哪些part文件。merge接口是最后一擊前端把所有分片都傳完后通知后端合并。這個接口不能少因為如果每傳一片就直接往最終文件尾部追加網絡亂序會讓你根本無法還原文件正確做法是先落盤成獨立分片最后統(tǒng)一排序合并。3.2 分片落盤與斷點記錄后端我用Express multer來接分片。multer是表單文件處理的標準庫配置磁盤存儲后文件會自動保存到指定目錄我們只需要在存儲配置里把req.body里的hash和index取出來拼路徑即可。const path require(path) const fs require(fs) const multer require(multer) const upload multer({ storage: multer.diskStorage({ destination(req, file, cb) { const dir path.join(UPLOAD_DIR, req.body.hash) fs.mkdirSync(dir, { recursive: true }) cb(null, dir) }, filename(req, file, cb) { cb(null, ${req.body.index}.part) } }) }) app.post(/api/upload, upload.single(file), (req, res) { res.json({ code: 0, message: ok }) })很多初次寫斷點續(xù)傳的人會在這里犯一個錯誤在destination回調里通過req.body拿到字段。如果你去打印發(fā)現(xiàn)req.body是空的原因通常是multipart字段順序不對。multer解析表單時文件字段之前的文本字段會先進入req.body所以前端構造FormData時最好把hash和index放在file字段之前append這個問題就自然消失了const formData new FormData() formData.append(hash, fileHash.value) // 先放文本字段 formData.append(index, index) formData.append(file, chunk) // 再放文件斷點記錄不需要引入數(shù)據庫因為文件系統(tǒng)本身就是記錄某個hash目錄下有多少個part文件已經自然記錄了上傳進度。check接口做的事情就是讀目錄app.post(/api/check, (req, res) { const { hash } req.body const dir path.join(UPLOAD_DIR, hash) const uploaded fs.existsSync(dir) ? fs.readdirSync(dir).map((name) Number(name.split(.)[0])) : [] res.json({ code: 0, uploaded }) })在真實場景里如果你的服務端是多機部署或者有幾十萬人同時傳文件文件系統(tǒng)就不是可靠的記錄方式了那時候得換Redis之類的記住分片狀態(tài)。demo階段用文件系統(tǒng)邏輯最透明也最容易排查問題。3.3 合并分片時的順序與校驗問題合并接口收到請求后要讀取hash目錄下所有part文件按序號從小到大依次寫入最終文件。順序錯了整個文件就是亂碼。寫合并邏輯時有兩點值得注意。第一sort不能直接按文件名字符串來因為10.part會排在2.part前面必須把文件名里的序號解析成數(shù)字再比較。第二大文件合并不要用readFileSync把所有分片同時讀進內存幾個GB的文件可能會把Node進程內存撐爆。正確姿勢是用流式管道或者用ReadableStream的異步迭代邊讀邊寫const { createReadStream, createWriteStream, existsSync, mkdirSync, readdirSync } require(fs) async function mergeChunks(hash, name) { const dir path.join(UPLOAD_DIR, hash) const chunkFiles readdirSync(dir) .filter((item) item.endsWith(.part)) .sort((a, b) Number(a.split(.)[0]) - Number(b.split(.)[0])) const outputPath path.join(MERGED_DIR, ${Date.now()}-${name}) if (!existsSync(MERGED_DIR)) mkdirSync(MERGED_DIR, { recursive: true }) const ws createWriteStream(outputPath) for (const file of chunkFiles) { const rs createReadStream(path.join(dir, file)) for await (const data of rs) { if (!ws.write(data)) { await new Promise((resolve) ws.once(drain, resolve)) } } } ws.end() await new Promise((resolve, reject) { ws.on(finish, resolve) ws.on(error, reject) }) }合并完成后強烈建議用絕對路徑讀寫文件避免文件名里帶上../或者/之類的路徑穿越問題。真實項目中文件名不能直接拿來拼路徑應該用hash作為存儲名或者做一層白名單過濾demo里用name主要是方便看到合并結果。注意不要在真實項目里讓用戶傳來的文件名直接落盤一定要對文件名做清洗或重命名。這是很多文件上傳服務被上傳惡意文件的入口。4. 完整DEMO實操從前端Vue到后端Node的落地過程4.1 初始化工程與依賴先建一個最簡單的工程。我特意不引入復雜的腳手架只保留能跑通斷點續(xù)傳的核心依賴方便你放進自己的項目里改造。mkdir vue-big-file-upload-demo cd vue-big-file-upload-demo npm init -y npm install express multer axios spark-md5 npm install -D vite vitejs/plugin-vue后端部分需要express和multer前端部分需要axios和spark-md5。vite只是demo的啟動工具你可以理解成幫我們把Vue單文件組件編譯到瀏覽器能跑的程度。目錄結構我習慣把前后端放在同一個工程里前端代碼放src后端代碼放servervue-big-file-upload-demo ├── src │ ├── App.vue │ └── main.js ├── server │ └── index.js ├── index.html ├── vite.config.js └── package.jsonvite.config.js里配置devServer代理把/api開頭的請求轉發(fā)到后端的3000端口import { defineConfig } from vite import vue from vitejs/plugin-vue export default defineConfig({ plugins: [vue()], server: { port: 5173, proxy: { /api: http://localhost:3000 } } })main.js和index.html最簡單能掛載App.vue就行// src/main.js import { createApp } from vue import App from ./App.vue createApp(App).mount(#app)!-- index.html -- !DOCTYPE html html head title大文件斷點續(xù)傳DEMO/title /head body div idapp/div script typemodule src/src/main.js/script /body /html4.2 前端頁面與上傳邏輯App.vue是整個demo的前端核心。我用ref維護文件對象、hash、已上傳分片集合和進度再用一個上傳狀態(tài)字段標記當前處于“計算hash中、上傳中、已暫停、已完成”哪個階段。這三個狀態(tài)字段看著簡單但斷點續(xù)傳最怕的就是前端狀態(tài)沒管好。template div input typefile changehandleFileChange / button clickstartUpload上傳/button button clickpauseUpload暫停/button button clickresumeUpload續(xù)傳/button div文件指紋{{ fileHash || 等待計算 }}/div div總體進度{{ percent }}%/div div狀態(tài){{ status }}/div /div /template script setup import { ref } from vue import axios from axios import SparkMD5 from spark-md5 const CHUNK_SIZE 4 * 1024 * 1024 const file ref(null) const fileHash ref() const uploadedIndexes ref([]) const totalChunkCount ref(0) const percent ref(0) const status ref(idle) const pauseFlag ref(false) const cancelControllers ref([]) function handleFileChange(e) { file.value e.target.files[0] } function createChunks(sourceFile) { const chunks [] let start 0 while (start sourceFile.size) { const end Math.min(start CHUNK_SIZE, sourceFile.size) chunks.push(sourceFile.slice(start, end)) start end } return chunks } async function calcHash(sourceFile) { const spark new SparkMD5.ArrayBuffer() let offset 0 while (offset sourceFile.size) { const chunk sourceFile.slice(offset, offset CHUNK_SIZE) spark.append(await chunk.arrayBuffer()) offset CHUNK_SIZE } return spark.end() } async function uploadChunk(chunk, index) { const formData new FormData() formData.append(hash, fileHash.value) formData.append(index, index) formData.append(file, chunk) const controller new AbortController() cancelControllers.value.push(controller) try { await axios.post(/api/upload, formData, { signal: controller.signal }) uploadedIndexes.value.push(index) percent.value Math.round((uploadedIndexes.value.length / totalChunkCount.value) * 100) } finally { const i cancelControllers.value.indexOf(controller) if (i -1) cancelControllers.value.splice(i, 1) } } async function runTaskWithLimit(pendingList, limit) { let cursor 0 const runWorker async () { while (cursor pendingList.length) { if (pauseFlag.value) return const current cursor const item pendingList[current] try { await uploadChunk(item.chunk, item.index) } catch (e) { if (pauseFlag.value) return // 網絡失敗時重試一次 await uploadChunk(item.chunk, item.index) } } } const workers [] for (let i 0; i Math.min(limit, pendingList.length); i) { workers.push(runWorker()) } await Promise.all(workers) } async function startUpload() { const sourceFile file.value if (!sourceFile) return status.value computing-hash pauseFlag.value false fileHash.value await calcHash(sourceFile) const chunks createChunks(sourceFile) totalChunkCount.value chunks.length status.value checking const { data } await axios.post(/api/check, { hash: fileHash.value }) const uploaded data.uploaded || [] uploadedIndexes.value uploaded if (uploaded.length 0) { percent.value Math.round((uploaded.length / totalChunkCount.value) * 100) } const pending chunks .map((chunk, index) ({ chunk, index })) .filter((item) !uploaded.includes(item.index)) if (pending.length 0) { await mergeRequest(sourceFile) status.value done percent.value 100 return } status.value uploading try { await runTaskWithLimit(pending, 3) if (pauseFlag.value) return await mergeRequest(sourceFile) status.value done percent.value 100 } catch (e) { status.value failed } } async function mergeRequest(sourceFile) { await axios.post(/api/merge, { hash: fileHash.value, name: sourceFile.name, total: totalChunkCount.value }) } function pauseUpload() { pauseFlag.value true status.value paused cancelControllers.value.forEach((controller) controller.abort()) } function resumeUpload() { if (!file.value) return startUpload() } /script這段代碼里有一個很重要的細節(jié)上傳成功后立即把index推進uploadedIndexes數(shù)組并刷新進度這樣即使頁面中途刷新下一次續(xù)傳也能通過check接口拿回這些記錄。另一個細節(jié)是暫停時調用controller.abort讓正在傳輸?shù)腶xios請求真的中斷而不是只把標志位改成true等著它自己跑完。之所以用AbortController而不是axios舊版的cancelToken是因為這是現(xiàn)在更推薦的標準方式axios新版也支持signal配置。4.3 后端服務完整實現(xiàn)server/index.js里放一個完整的Express服務包含前面說的三個接口。為了演示直接我合并文件時用時間戳加原始文件名作為輸出文件名但真實項目里建議換成hash加后綴可讀性差一點安全性高很多。const express require(express) const multer require(multer) const fs require(fs) const path require(path) const app express() const PORT 3000 const UPLOAD_DIR path.join(__dirname, uploads) const MERGED_DIR path.join(__dirname, merged) fs.mkdirSync(UPLOAD_DIR, { recursive: true }) fs.mkdirSync(MERGED_DIR, { recursive: true }) app.use(express.json()) const storage multer.diskStorage({ destination(req, file, cb) { const dir path.join(UPLOAD_DIR, req.body.hash) fs.mkdirSync(dir, { recursive: true }) cb(null, dir) }, filename(req, file, cb) { cb(null, ${req.body.index}.part) } }) const upload multer({ storage }) app.post(/api/upload, upload.single(file), (req, res) { res.json({ code: 0, message: chunk uploaded, index: Number(req.body.index) }) }) app.post(/api/check, (req, res) { const { hash } req.body const dir path.join(UPLOAD_DIR, hash) if (!fs.existsSync(dir)) { return res.json({ code: 0, uploaded: [] }) } const uploaded fs.readdirSync(dir) .filter((name) name.endsWith(.part)) .map((name) Number(name.split(.)[0])) res.json({ code: 0, uploaded }) }) app.post(/api/merge, async (req, res) { const { hash, name, total } req.body const dir path.join(UPLOAD_DIR, hash) if (!fs.existsSync(dir)) { return res.status(400).json({ code: 1, message: 分片目錄不存在 }) } const partFiles fs.readdirSync(dir) .filter((item) item.endsWith(.part)) .sort((a, b) Number(a.split(.)[0]) - Number(b.split(.)[0])) if (partFiles.length ! Number(total)) { return res.status(400).json({ code: 1, message: 分片數(shù)量不完整 }) } const outputPath path.join(MERGED_DIR, ${Date.now()}-${name}) const ws fs.createWriteStream(outputPath) for (const partFile of partFiles) { const rs fs.createReadStream(path.join(dir, partFile)) try { for await (const data of rs) { if (!ws.write(data)) { await new Promise((resolve) ws.once(drain, resolve)) } } } catch (e) { ws.destroy(e) return res.status(500).json({ code: 1, message: 合并失敗 }) } } ws.end() ws.on(finish, () res.json({ code: 0, message: merge ok, filePath: outputPath })) ws.on(error, (e) res.status(500).json({ code: 1, message: e.message })) }) app.listen(PORT, () { console.log(server running at http://localhost:${PORT}) })這里merge接口里對分片總數(shù)做了一個校驗前端傳過來的total必須等于實際part文件數(shù)量否則直接拒絕合并。這是防止“漏傳了幾個分片就去合并”的第一道防線但只靠數(shù)量校驗還不夠更好的做法是校驗所有分片大小之和是否等于原始文件大小或者合并后重新計算整文件hash。4.4 完整請求時序與體驗對照跑起來之后一個典型的斷點續(xù)傳請求鏈路是這樣的用戶選擇文件前端切片并計算hash狀態(tài)顯示“正在計算”。前端POST /api/check拿到服務端已存在的分片序號數(shù)組。前端過濾出剩余分片以3路并發(fā)逐片POST /api/upload。每傳完一片前端將index加入已上傳集合進度條前進一步。全部傳完后POST /api/merge服務端按index排序合并返回最終文件路徑。第一次全量傳可能要幾十秒。第二次選擇同一個文件再上傳check接口直接返回所有分片序號已存在前端不會發(fā)出任何upload請求直接走merge整個過程在1秒內完成這就是秒傳。中斷的體驗也能復現(xiàn)上傳到一半直接把后端進程殺掉前端會拋出一堆請求失敗然后暫停再重啟后端點續(xù)傳前端重新計算hash后通過check發(fā)現(xiàn)已經上傳了前10片就從第11片開始繼續(xù)傳剩余分片都是秒過。這個過程中真正網絡傳輸?shù)闹挥兄袛嗪笫Ｓ嗟牟糠智懊娴姆制粋€都沒有重傳。5. 斷點續(xù)傳DEMO里最容易踩的坑我?guī)湍阏砗昧?.1 hash怎么算才不卡UIdemo里我為了可讀性直接把hash計算放在主線程小文件沒問題一旦文件超過1GB你就能明顯看到頁面卡在“計算中”轉圈按鈕點不動。原因很簡單spark-md5的ArrayBuffer.append雖然每次只處理一個分片但整個計算循環(huán)占著主線程的事件循環(huán)Vue的響應式更新根本沒機會插進來。解決辦法是放進Web Worker。把分片讀取和spark-md5計算全部丟到worker里主線程只負責接收最后的hash字符串和進度。還有一個折中方案在主線程計算時每隔幾個分片await一次setTimeout或requestAnimationFrame讓出事件循環(huán)界面能保持響應但是對超大文件仍然不夠穩(wěn)。真實項目里我建議直接開Worker并且把“計算hash”也做成可中斷的否則用戶等了幾十秒想取消算到一半也退不掉。另一個性能問題是讀文件的方式。chunk.arrayBuffer()會把這一片完整拷進內存4MB一片沒問題但如果你大面積用整文件arrayBuffer幾個GB的文件直接內存溢出。demo里我始終基于切片來讀這一點不要改成file.arrayBuffer()一次性讀取。5.2 分片大小和并發(fā)數(shù)到底怎么配分片大小和并發(fā)數(shù)是斷點續(xù)傳最影響吞吐的兩個參數(shù)它們的合理值取決于你的用戶網絡環(huán)境。我整理了一份經驗值可以直接當初始基準場景推薦分片大小推薦并發(fā)數(shù)公網普通寬帶、用戶量大2MB-4MB3內網高速、服務端帶寬充足5MB-10MB5-8手機弱網環(huán)境1MB-2MB2-3公網環(huán)境并發(fā)數(shù)別開太大看起來快實際上容易觸發(fā)服務端連接數(shù)上限、代理超時一個分片失敗還會帶動整條連接排隊。弱網環(huán)境分片小一點這樣中斷發(fā)生時損失的字節(jié)更少重試速度也更快。這些值可以在后臺做成配置項按文件大小動態(tài)調整比如小于100MB走普通單請求大于100MB再啟用分片。還有一個容易忽略的參數(shù)是axios的超時時間。給每個分片請求設置一個合理的timeout比如30秒不要讓一個分片卡在服務端永遠等下去否則所有worker都等在同一片上后續(xù)分片全部排隊表現(xiàn)就是進度條卡住不動。5.3 斷點失效、秒傳失敗、進度不準逐個排查先看最常見的“斷點續(xù)傳不生效”重新打開頁面選擇同一個文件check接口返回的uploaded卻是空數(shù)組。這種情況十有八九是hash對不上檢查點有這幾個前端hash計算是否基于原始文件的完整內容有沒有因為切片邊界算錯。后端保存分片目錄時是否真的用了hash而不是用索引值拼錯路徑。同一個文件在前后兩次選擇時File對象的size和lastModified是否一致。如果文件內容沒變但hash不同多半是讀取邏輯里混入了無關字節(jié)。再看“秒傳失敗”所有分片明明都在前端還是把幾百個分片重新傳了一遍。先把check接口返回的數(shù)組打印出來如果返回的index是字符串而前端用includes判斷時類型不匹配就會全部判斷成不存在。這是JavaScript弱類型最容易踩的坑之一要么后端返回數(shù)字要么前端parseInt之后再去includes。進度不準的問題多數(shù)出在進度計算公式上。整個上傳過程其實包含hash計算和上傳兩個階段很多人只算了上傳階段的片數(shù)百分比用戶從0%開始等hash算了半天進度一直是0體驗很差。我的習慣是給hash計算分配一個固定小百分比比如5%上傳階段占95%然后總體進度等于hash階段完成后5%再加上uploadedIndexes.length / totalChunkCount * 95。最后一個坑是關于端口和代理的。Vite開發(fā)服務器默認5173后端3000如果跨域或不走代理前端發(fā)出的/api請求會404。我建議demo里統(tǒng)一通過vite的proxy轉發(fā)生產環(huán)境則用nginx把/api反代到后端這是最不容易出問題的部署姿勢。6. 演示之外我把這套方案搬進真實項目的經驗demo寫完之后我在自己維護的一個網盤類小工具里把這套邏輯改了改上線遇到了一些demo里沒有體現(xiàn)的問題分享幾個方向你可以作為下一步擴展的參考。第一是取消和續(xù)傳的狀態(tài)管理。demo里暫停用一個布爾標志位搞定但真實場景用戶可能在上傳中刷新頁面、切走再回來前端需要把上傳任務持久化到localStorage甚至IndexedDB記錄文件hash、分片序號和進度。重新加載后先恢復任務列表再逐個調check接口確定真實進度。這一步不做用戶中途刷新一次前面?zhèn)鞯钠腿皝G了”心智雖然服務端物理上還在但前端不知道從哪里繼續(xù)。第二是Web Worker里跑hash。我在worker里維護了一個“取消計算”的信號主線程傳給worker或者直接調用worker.terminate()用戶取消上傳時能把hash計算立刻停下來。這一改動對體驗的提升非常明顯尤其面對10GB以上的文件hash計算可能要好幾分鐘。第三是服務端的整潔度。文件系統(tǒng)做斷點記錄在單機demo里很舒服但上線后最好把“分片狀態(tài)”抽到Redis緩存文件本體放對象存儲或者分布式文件系統(tǒng)合并操作交給后端異步任務隊列去跑而不是在HTTP請求里同步讀寫大文件。同步讀寫會導致請求一直掛著網關很快超時斷開合并卻還在后臺寫文件返回包用戶根本收不到。如果只是要一個能跑的DEMO照著上面的代碼敲一遍就夠了如果要把斷點續(xù)傳做成生產功能分片存儲、失敗重試、秒傳校驗、權限控制這幾個模塊都值得單獨花時間打磨。我現(xiàn)在回看這個項目最大的收獲不是某個API有多難而是“把大問題拆成小問題、再對小問題分別處理”這個思路在斷點續(xù)傳里體現(xiàn)得尤其明顯。真遇到大文件傳輸需求時先別急著找現(xiàn)成的上傳組件把文件分片、hash指紋、斷點記錄這三件事想清楚代碼自然就出來了。 Vue3+Node.js大文件斷點續(xù)傳：文件分片、hash計算與并發(fā)上傳實踐
看到這個標題我想你大概是遇到了一個現(xiàn)實問題項目里要傳幾百MB甚至幾個G的文件結果每次傳到一半就斷要不就是頁面卡死、用戶關掉又重新從0%開始。這套基于JavaScript、Vue、Node.js寫出來的大文件斷點續(xù)傳DEMO就是為了解決這個痛點。我會用Vue 3配合File API里的slice方法做文件分片用spark-md5計算文件hash再用axios并發(fā)上傳分片最后寫一個不算復雜的Node.js服務端做分片存儲和合并。整個過程下來有Vue基礎的人照著敲一遍就能跑通也能理解斷點續(xù)傳背后的原理。1. 先把斷點續(xù)傳這件事想明白拆片、記錄、重組1.1 一次上傳為什么靠不住在開始寫DEMO之前先倒回去想一個問題為什么不能直接拿一個文件往后端丟不是不能而是現(xiàn)實世界里大文件直接傳輸?shù)捏w驗非常差。瀏覽器里的File對象本質上是一個Blob你把一個幾個GB的文件塞進FormData一個HTTP請求發(fā)出后整個請求體一直占著網絡連接服務器那邊如果用的是Express這類框架默認也會對整個請求做緩沖內存一下就繃緊。更關鍵的是傳輸中間只要有一點抖動TCP連接斷了整個請求就沒了瀏覽器不會因為文件太大就對你手下留情用戶體驗就是“卡在99%然后重來”。還有一個容易被忽略的問題很多網關和Web服務器對單次請求體都有硬性限制Nginx默認的client_max_body_size很小就算你配置了十幾GB也架不住中間機器超時回收。所以“把一個文件變成很多個小文件分別上傳”是繞開這些限制的最實用手段這也是斷點續(xù)傳方案的核心一個文件被切成N片每片都是一個獨立請求失敗了對單一片重試而不是對整個文件重試。1.2 斷點續(xù)傳和普通上傳到底差在哪普通上傳里文件的二進制流從頭傳到尾中間任何一個地方斷掉已經傳出去的字節(jié)就全部作廢。斷點續(xù)傳則圍繞“狀態(tài)”來做文章先記住這個文件的唯一身份再記住哪些分片已經上傳成功下次重新打開頁面或者點擊續(xù)傳時只需要從沒傳過的分片繼續(xù)已經傳過的分片直接跳過。這個“記住”的過程就是后端只認hash和分片序號hash是文件指紋分片序號是位置。把斷點續(xù)傳和完整上傳放在一起對比差異就非常明顯傳輸粒度完整上傳是單一數(shù)據流斷點續(xù)傳是一個個獨立分片。失敗成本完整上傳一旦失敗全部重來斷點續(xù)傳只需要重傳失敗的那幾片理想狀態(tài)下接近零成本?？蓵和Ｐ酝暾蟼鞑荒苤型緯和；謴蛿帱c續(xù)傳隨時可以暫停下次繼續(xù)。秒傳能力如果服務端已經保存過同樣hash的文件可以直接提示上傳完成根本不用再上傳。這些差異是斷點續(xù)傳被選來對付大文件的核心原因。1.3 整體方案選型為什么選Vue 3 Node.js嚴格說起來斷點續(xù)傳是前端工程和前后端契約共同完成的不涉及什么黑魔法。demo里我用的組合是Vue 3 axios spark-md5后端用Node.js Express multer主要是因為這套組合和你標題里的“JavaScript怎么編寫”完全在一個語言體系里前端JavaScript負責切片、算hash、并發(fā)控制后端JavaScript負責收分片、存狀態(tài)、合并文件前后端不需要切換技術?？雌饋砀槨ue 3的Composition API在管理上傳任務時比Vue 2的Options API直觀得多ref、computed這些響應式原語能把文件、hash、已上傳分片、進度這些狀態(tài)統(tǒng)一管理起來。demo里我不會引入太重量的UI庫直接用原生button和簡單的div滾動條因為斷點續(xù)傳的核心不在UI組件而在于分片、hash和狀態(tài)同步你以后接Element Plus還是Ant Design Vue都很容易。提示如果你在真實項目里用的是React、Angular或原生JS這套思路同樣成立因為真正核心的是File.slice、FormData和XHR/fetch這些瀏覽器標準API框架只是外層殼。2. 前端分片與指紋計算從代碼層面吃透2.1 用 Blob.slice 把大文件切成小塊文件分片最根本的API就是Blob.prototype.sliceFile繼承自Blob所以可以直接file.slice(start, end)拿到原文件的一部分。這個操作不是把文件物理切開而是生成一個新的Blob底層可能仍然引用原文件的內存區(qū)域所以性能很高不會因為切一下就把大文件整個復制一遍。以4MB為一片舉例分片邏輯如下const CHUNK_SIZE 4 * 1024 * 1024 function createFileChunks(file) { const chunks [] let start 0 while (start file.size) { const end Math.min(start CHUNK_SIZE, file.size) const chunk file.slice(start, end) chunks.push(chunk) start end } return chunks }這里有幾個細節(jié)要特別注意。第一最后一片的大小往往小于CHUNK_SIZE切片時end要用Math.min兜住文件大小否則會拿到一個空的Blob。第二每個分片必須帶上它在整個文件中的序號否則服務端合并時不知道先后順序這也就是后面接口里一直出現(xiàn)的index字段。第三切片時盡量讓每片大小保持一致這樣服務端合并、前端重試時邏輯都簡單。實際上分片大小不是一個固定的最佳值我見過很多人直接套一個“5MB”到處用。片越小請求數(shù)量越多服務端文件句柄和前端Promise對象都會壓滿片越大單請求傳輸時間越長斷點續(xù)傳的“續(xù)”就變得不精細。通常我建議從2MB到10MB之間取值公網環(huán)境取4MB左右比較平衡內網環(huán)境可以放大到10MB請求數(shù)量和恢復精度都兼顧了。2.2 用 spark-md5 算出文件唯一指紋分片之后遇到第一個問題怎么讓服務端知道“這兩個文件其實是同一個”最可靠的方案不是文件名因為同名文件內容可以完全不一樣也不是文件大小因為大小相同內容也可能不同而是給文件內容本身算一個摘要也就是hash。前端把整個文件的hash發(fā)給后端后端拿hash作為分片目錄名這樣同一個文件即使你改了文件名再傳也能直接續(xù)上。spark-md5是前端算文件hash最常用的庫它支持增量計算可以邊讀分片邊更新hash不用一口氣把整個文件讀進內存。核心代碼如下import SparkMD5 from spark-md5 async function calcFileHash(file) { const spark new SparkMD5.ArrayBuffer() let offset 0 while (offset file.size) { const chunk file.slice(offset, offset CHUNK_SIZE) const buffer await chunk.arrayBuffer() spark.append(buffer) offset CHUNK_SIZE } return spark.end() }這里值得說一下ArrayBuffer模式spark.append可以接收ArrayBuffer、binary string等對大文件來說用ArrayBuffer模式的性能更好因為瀏覽器底層可以直接給你二進制內存塊。每次循環(huán)只把當前這一片讀成buffer算完就釋放內存占用量被控制在一個分片大小內。如果文件達到了幾個GB這個計算過程可能要花幾十秒為了不阻塞界面真實項目最好放到Web Worker里跑demo階段為了少繞一圈直接放主線程后面我會專門講怎么處理卡UI的問題。有一點必須提前說清楚hash算出來的值只代表你本地看到的內容不代表傳輸過程中沒有損壞。真正要求嚴謹?shù)膱鼍胺斩嗽诤喜⑼瓿珊筮€要再算一次hash和前端提交的hash比對不一致就說明傳壞了。demo里我會在合并接口里做一次最簡單的數(shù)量校驗。2.3 分片上傳并發(fā)控制的實現(xiàn)思路分片準備好了hash也有了是不是直接把所有分片一次性全部發(fā)出去不行。幾百個分片同時發(fā)起請求瀏覽器連接數(shù)有限服務器也會被瞬間打掛進度條回升得又慢又不穩(wěn)定。正確做法是控制并發(fā)比如最多同時傳3到5片。并發(fā)控制寫起來一點都不難核心就是一個消費者隊列維護一個游標分給固定數(shù)量的worker去消費待上傳列表每個worker取到一片傳一片傳完繼續(xù)取下一下片直到全部消費完。我習慣寫成這樣async function uploadWithConcurrency(pendingList, poolLimit) { let cursor 0 const workers [] const runWorker async () { while (cursor pendingList.length) { const current cursor const item pendingList[current] await uploadChunk(item.chunk, item.index) } } const workerCount Math.min(poolLimit, pendingList.length) for (let i 0; i workerCount; i) { workers.push(runWorker()) } await Promise.all(workers) }這樣寫的好處是讓每個worker異步循環(huán)拉任務而不是先分配固定任務這樣慢的分片不會拖累其他worker。實際跑的時候你可以在uploadChunk里給每個分片附加index和hash并在成功后把index記錄進已上傳集合中。暫停功能的核心也是這個隊列暫停時用一個標志位讓worker的while循環(huán)直接退出并且取消掉正在進行的axios請求恢復時用當前已上傳集合過濾出還沒傳的分片重新建一個隊列跑起來。3. 服務端接口怎么設計才能支撐前端這套玩法3.1 約定三個核心接口check、upload、merge前端和后端的分工必須通過接口契約固定下來demo里我把它收成三個接口這也是大多數(shù)斷點續(xù)傳服務的最小集合接口方法核心參數(shù)職責/api/checkPOSThash查詢服務端已存在哪些分片序號/api/uploadPOSTfile、hash、index上傳單個分片/api/mergePOSThash、name、total通知服務端合并所有分片check接口的作用是“斷點查詢”。用戶打開頁面重新選擇一個文件前端算完hash后先問服務端這個文件傳過嗎傳到了第幾片服務端把已有分片的索引數(shù)組返回給前端前端過濾掉這些序號只傳剩下的。這個接口讓“續(xù)傳”真正成立不然每次重開頁面都不知道從哪里繼續(xù)。upload接口接收的就是某一個分片的二進制這里有個重要約定分片必須帶hash和index。hash決定它落到哪個目錄index決定它在合并時的位置。為了簡化設計后端按hash建目錄目錄里的文件名直接就是“index.part”查找已上傳分片就是讀取目錄下有哪些part文件。merge接口是最后一擊前端把所有分片都傳完后通知后端合并。這個接口不能少因為如果每傳一片就直接往最終文件尾部追加網絡亂序會讓你根本無法還原文件正確做法是先落盤成獨立分片最后統(tǒng)一排序合并。3.2 分片落盤與斷點記錄后端我用Express multer來接分片。multer是表單文件處理的標準庫配置磁盤存儲后文件會自動保存到指定目錄我們只需要在存儲配置里把req.body里的hash和index取出來拼路徑即可。const path require(path) const fs require(fs) const multer require(multer) const upload multer({ storage: multer.diskStorage({ destination(req, file, cb) { const dir path.join(UPLOAD_DIR, req.body.hash) fs.mkdirSync(dir, { recursive: true }) cb(null, dir) }, filename(req, file, cb) { cb(null, ${req.body.index}.part) } }) }) app.post(/api/upload, upload.single(file), (req, res) { res.json({ code: 0, message: ok }) })很多初次寫斷點續(xù)傳的人會在這里犯一個錯誤在destination回調里通過req.body拿到字段。如果你去打印發(fā)現(xiàn)req.body是空的原因通常是multipart字段順序不對。multer解析表單時文件字段之前的文本字段會先進入req.body所以前端構造FormData時最好把hash和index放在file字段之前append這個問題就自然消失了const formData new FormData() formData.append(hash, fileHash.value) // 先放文本字段 formData.append(index, index) formData.append(file, chunk) // 再放文件斷點記錄不需要引入數(shù)據庫因為文件系統(tǒng)本身就是記錄某個hash目錄下有多少個part文件已經自然記錄了上傳進度。check接口做的事情就是讀目錄app.post(/api/check, (req, res) { const { hash } req.body const dir path.join(UPLOAD_DIR, hash) const uploaded fs.existsSync(dir) ? fs.readdirSync(dir).map((name) Number(name.split(.)[0])) : [] res.json({ code: 0, uploaded }) })在真實場景里如果你的服務端是多機部署或者有幾十萬人同時傳文件文件系統(tǒng)就不是可靠的記錄方式了那時候得換Redis之類的記住分片狀態(tài)。demo階段用文件系統(tǒng)邏輯最透明也最容易排查問題。3.3 合并分片時的順序與校驗問題合并接口收到請求后要讀取hash目錄下所有part文件按序號從小到大依次寫入最終文件。順序錯了整個文件就是亂碼。寫合并邏輯時有兩點值得注意。第一sort不能直接按文件名字符串來因為10.part會排在2.part前面必須把文件名里的序號解析成數(shù)字再比較。第二大文件合并不要用readFileSync把所有分片同時讀進內存幾個GB的文件可能會把Node進程內存撐爆。正確姿勢是用流式管道或者用ReadableStream的異步迭代邊讀邊寫const { createReadStream, createWriteStream, existsSync, mkdirSync, readdirSync } require(fs) async function mergeChunks(hash, name) { const dir path.join(UPLOAD_DIR, hash) const chunkFiles readdirSync(dir) .filter((item) item.endsWith(.part)) .sort((a, b) Number(a.split(.)[0]) - Number(b.split(.)[0])) const outputPath path.join(MERGED_DIR, ${Date.now()}-${name}) if (!existsSync(MERGED_DIR)) mkdirSync(MERGED_DIR, { recursive: true }) const ws createWriteStream(outputPath) for (const file of chunkFiles) { const rs createReadStream(path.join(dir, file)) for await (const data of rs) { if (!ws.write(data)) { await new Promise((resolve) ws.once(drain, resolve)) } } } ws.end() await new Promise((resolve, reject) { ws.on(finish, resolve) ws.on(error, reject) }) }合并完成后強烈建議用絕對路徑讀寫文件避免文件名里帶上../或者/之類的路徑穿越問題。真實項目中文件名不能直接拿來拼路徑應該用hash作為存儲名或者做一層白名單過濾demo里用name主要是方便看到合并結果。注意不要在真實項目里讓用戶傳來的文件名直接落盤一定要對文件名做清洗或重命名。這是很多文件上傳服務被上傳惡意文件的入口。4. 完整DEMO實操從前端Vue到后端Node的落地過程4.1 初始化工程與依賴先建一個最簡單的工程。我特意不引入復雜的腳手架只保留能跑通斷點續(xù)傳的核心依賴方便你放進自己的項目里改造。mkdir vue-big-file-upload-demo cd vue-big-file-upload-demo npm init -y npm install express multer axios spark-md5 npm install -D vite vitejs/plugin-vue后端部分需要express和multer前端部分需要axios和spark-md5。vite只是demo的啟動工具你可以理解成幫我們把Vue單文件組件編譯到瀏覽器能跑的程度。目錄結構我習慣把前后端放在同一個工程里前端代碼放src后端代碼放servervue-big-file-upload-demo ├── src │ ├── App.vue │ └── main.js ├── server │ └── index.js ├── index.html ├── vite.config.js └── package.jsonvite.config.js里配置devServer代理把/api開頭的請求轉發(fā)到后端的3000端口import { defineConfig } from vite import vue from vitejs/plugin-vue export default defineConfig({ plugins: [vue()], server: { port: 5173, proxy: { /api: http://localhost:3000 } } })main.js和index.html最簡單能掛載App.vue就行// src/main.js import { createApp } from vue import App from ./App.vue createApp(App).mount(#app)!-- index.html -- !DOCTYPE html html head title大文件斷點續(xù)傳DEMO/title /head body div idapp/div script typemodule src/src/main.js/script /body /html4.2 前端頁面與上傳邏輯App.vue是整個demo的前端核心。我用ref維護文件對象、hash、已上傳分片集合和進度再用一個上傳狀態(tài)字段標記當前處于“計算hash中、上傳中、已暫停、已完成”哪個階段。這三個狀態(tài)字段看著簡單但斷點續(xù)傳最怕的就是前端狀態(tài)沒管好。template div input typefile changehandleFileChange / button clickstartUpload上傳/button button clickpauseUpload暫停/button button clickresumeUpload續(xù)傳/button div文件指紋{{ fileHash || 等待計算 }}/div div總體進度{{ percent }}%/div div狀態(tài){{ status }}/div /div /template script setup import { ref } from vue import axios from axios import SparkMD5 from spark-md5 const CHUNK_SIZE 4 * 1024 * 1024 const file ref(null) const fileHash ref() const uploadedIndexes ref([]) const totalChunkCount ref(0) const percent ref(0) const status ref(idle) const pauseFlag ref(false) const cancelControllers ref([]) function handleFileChange(e) { file.value e.target.files[0] } function createChunks(sourceFile) { const chunks [] let start 0 while (start sourceFile.size) { const end Math.min(start CHUNK_SIZE, sourceFile.size) chunks.push(sourceFile.slice(start, end)) start end } return chunks } async function calcHash(sourceFile) { const spark new SparkMD5.ArrayBuffer() let offset 0 while (offset sourceFile.size) { const chunk sourceFile.slice(offset, offset CHUNK_SIZE) spark.append(await chunk.arrayBuffer()) offset CHUNK_SIZE } return spark.end() } async function uploadChunk(chunk, index) { const formData new FormData() formData.append(hash, fileHash.value) formData.append(index, index) formData.append(file, chunk) const controller new AbortController() cancelControllers.value.push(controller) try { await axios.post(/api/upload, formData, { signal: controller.signal }) uploadedIndexes.value.push(index) percent.value Math.round((uploadedIndexes.value.length / totalChunkCount.value) * 100) } finally { const i cancelControllers.value.indexOf(controller) if (i -1) cancelControllers.value.splice(i, 1) } } async function runTaskWithLimit(pendingList, limit) { let cursor 0 const runWorker async () { while (cursor pendingList.length) { if (pauseFlag.value) return const current cursor const item pendingList[current] try { await uploadChunk(item.chunk, item.index) } catch (e) { if (pauseFlag.value) return // 網絡失敗時重試一次 await uploadChunk(item.chunk, item.index) } } } const workers [] for (let i 0; i Math.min(limit, pendingList.length); i) { workers.push(runWorker()) } await Promise.all(workers) } async function startUpload() { const sourceFile file.value if (!sourceFile) return status.value computing-hash pauseFlag.value false fileHash.value await calcHash(sourceFile) const chunks createChunks(sourceFile) totalChunkCount.value chunks.length status.value checking const { data } await axios.post(/api/check, { hash: fileHash.value }) const uploaded data.uploaded || [] uploadedIndexes.value uploaded if (uploaded.length 0) { percent.value Math.round((uploaded.length / totalChunkCount.value) * 100) } const pending chunks .map((chunk, index) ({ chunk, index })) .filter((item) !uploaded.includes(item.index)) if (pending.length 0) { await mergeRequest(sourceFile) status.value done percent.value 100 return } status.value uploading try { await runTaskWithLimit(pending, 3) if (pauseFlag.value) return await mergeRequest(sourceFile) status.value done percent.value 100 } catch (e) { status.value failed } } async function mergeRequest(sourceFile) { await axios.post(/api/merge, { hash: fileHash.value, name: sourceFile.name, total: totalChunkCount.value }) } function pauseUpload() { pauseFlag.value true status.value paused cancelControllers.value.forEach((controller) controller.abort()) } function resumeUpload() { if (!file.value) return startUpload() } /script這段代碼里有一個很重要的細節(jié)上傳成功后立即把index推進uploadedIndexes數(shù)組并刷新進度這樣即使頁面中途刷新下一次續(xù)傳也能通過check接口拿回這些記錄。另一個細節(jié)是暫停時調用controller.abort讓正在傳輸?shù)腶xios請求真的中斷而不是只把標志位改成true等著它自己跑完。之所以用AbortController而不是axios舊版的cancelToken是因為這是現(xiàn)在更推薦的標準方式axios新版也支持signal配置。4.3 后端服務完整實現(xiàn)server/index.js里放一個完整的Express服務包含前面說的三個接口。為了演示直接我合并文件時用時間戳加原始文件名作為輸出文件名但真實項目里建議換成hash加后綴可讀性差一點安全性高很多。const express require(express) const multer require(multer) const fs require(fs) const path require(path) const app express() const PORT 3000 const UPLOAD_DIR path.join(__dirname, uploads) const MERGED_DIR path.join(__dirname, merged) fs.mkdirSync(UPLOAD_DIR, { recursive: true }) fs.mkdirSync(MERGED_DIR, { recursive: true }) app.use(express.json()) const storage multer.diskStorage({ destination(req, file, cb) { const dir path.join(UPLOAD_DIR, req.body.hash) fs.mkdirSync(dir, { recursive: true }) cb(null, dir) }, filename(req, file, cb) { cb(null, ${req.body.index}.part) } }) const upload multer({ storage }) app.post(/api/upload, upload.single(file), (req, res) { res.json({ code: 0, message: chunk uploaded, index: Number(req.body.index) }) }) app.post(/api/check, (req, res) { const { hash } req.body const dir path.join(UPLOAD_DIR, hash) if (!fs.existsSync(dir)) { return res.json({ code: 0, uploaded: [] }) } const uploaded fs.readdirSync(dir) .filter((name) name.endsWith(.part)) .map((name) Number(name.split(.)[0])) res.json({ code: 0, uploaded }) }) app.post(/api/merge, async (req, res) { const { hash, name, total } req.body const dir path.join(UPLOAD_DIR, hash) if (!fs.existsSync(dir)) { return res.status(400).json({ code: 1, message: 分片目錄不存在 }) } const partFiles fs.readdirSync(dir) .filter((item) item.endsWith(.part)) .sort((a, b) Number(a.split(.)[0]) - Number(b.split(.)[0])) if (partFiles.length ! Number(total)) { return res.status(400).json({ code: 1, message: 分片數(shù)量不完整 }) } const outputPath path.join(MERGED_DIR, ${Date.now()}-${name}) const ws fs.createWriteStream(outputPath) for (const partFile of partFiles) { const rs fs.createReadStream(path.join(dir, partFile)) try { for await (const data of rs) { if (!ws.write(data)) { await new Promise((resolve) ws.once(drain, resolve)) } } } catch (e) { ws.destroy(e) return res.status(500).json({ code: 1, message: 合并失敗 }) } } ws.end() ws.on(finish, () res.json({ code: 0, message: merge ok, filePath: outputPath })) ws.on(error, (e) res.status(500).json({ code: 1, message: e.message })) }) app.listen(PORT, () { console.log(server running at http://localhost:${PORT}) })這里merge接口里對分片總數(shù)做了一個校驗前端傳過來的total必須等于實際part文件數(shù)量否則直接拒絕合并。這是防止“漏傳了幾個分片就去合并”的第一道防線但只靠數(shù)量校驗還不夠更好的做法是校驗所有分片大小之和是否等于原始文件大小或者合并后重新計算整文件hash。4.4 完整請求時序與體驗對照跑起來之后一個典型的斷點續(xù)傳請求鏈路是這樣的用戶選擇文件前端切片并計算hash狀態(tài)顯示“正在計算”。前端POST /api/check拿到服務端已存在的分片序號數(shù)組。前端過濾出剩余分片以3路并發(fā)逐片POST /api/upload。每傳完一片前端將index加入已上傳集合進度條前進一步。全部傳完后POST /api/merge服務端按index排序合并返回最終文件路徑。第一次全量傳可能要幾十秒。第二次選擇同一個文件再上傳check接口直接返回所有分片序號已存在前端不會發(fā)出任何upload請求直接走merge整個過程在1秒內完成這就是秒傳。中斷的體驗也能復現(xiàn)上傳到一半直接把后端進程殺掉前端會拋出一堆請求失敗然后暫停再重啟后端點續(xù)傳前端重新計算hash后通過check發(fā)現(xiàn)已經上傳了前10片就從第11片開始繼續(xù)傳剩余分片都是秒過。這個過程中真正網絡傳輸?shù)闹挥兄袛嗪笫Ｓ嗟牟糠智懊娴姆制粋€都沒有重傳。5. 斷點續(xù)傳DEMO里最容易踩的坑我?guī)湍阏砗昧?.1 hash怎么算才不卡UIdemo里我為了可讀性直接把hash計算放在主線程小文件沒問題一旦文件超過1GB你就能明顯看到頁面卡在“計算中”轉圈按鈕點不動。原因很簡單spark-md5的ArrayBuffer.append雖然每次只處理一個分片但整個計算循環(huán)占著主線程的事件循環(huán)Vue的響應式更新根本沒機會插進來。解決辦法是放進Web Worker。把分片讀取和spark-md5計算全部丟到worker里主線程只負責接收最后的hash字符串和進度。還有一個折中方案在主線程計算時每隔幾個分片await一次setTimeout或requestAnimationFrame讓出事件循環(huán)界面能保持響應但是對超大文件仍然不夠穩(wěn)。真實項目里我建議直接開Worker并且把“計算hash”也做成可中斷的否則用戶等了幾十秒想取消算到一半也退不掉。另一個性能問題是讀文件的方式。chunk.arrayBuffer()會把這一片完整拷進內存4MB一片沒問題但如果你大面積用整文件arrayBuffer幾個GB的文件直接內存溢出。demo里我始終基于切片來讀這一點不要改成file.arrayBuffer()一次性讀取。5.2 分片大小和并發(fā)數(shù)到底怎么配分片大小和并發(fā)數(shù)是斷點續(xù)傳最影響吞吐的兩個參數(shù)它們的合理值取決于你的用戶網絡環(huán)境。我整理了一份經驗值可以直接當初始基準場景推薦分片大小推薦并發(fā)數(shù)公網普通寬帶、用戶量大2MB-4MB3內網高速、服務端帶寬充足5MB-10MB5-8手機弱網環(huán)境1MB-2MB2-3公網環(huán)境并發(fā)數(shù)別開太大看起來快實際上容易觸發(fā)服務端連接數(shù)上限、代理超時一個分片失敗還會帶動整條連接排隊。弱網環(huán)境分片小一點這樣中斷發(fā)生時損失的字節(jié)更少重試速度也更快。這些值可以在后臺做成配置項按文件大小動態(tài)調整比如小于100MB走普通單請求大于100MB再啟用分片。還有一個容易忽略的參數(shù)是axios的超時時間。給每個分片請求設置一個合理的timeout比如30秒不要讓一個分片卡在服務端永遠等下去否則所有worker都等在同一片上后續(xù)分片全部排隊表現(xiàn)就是進度條卡住不動。5.3 斷點失效、秒傳失敗、進度不準逐個排查先看最常見的“斷點續(xù)傳不生效”重新打開頁面選擇同一個文件check接口返回的uploaded卻是空數(shù)組。這種情況十有八九是hash對不上檢查點有這幾個前端hash計算是否基于原始文件的完整內容有沒有因為切片邊界算錯。后端保存分片目錄時是否真的用了hash而不是用索引值拼錯路徑。同一個文件在前后兩次選擇時File對象的size和lastModified是否一致。如果文件內容沒變但hash不同多半是讀取邏輯里混入了無關字節(jié)。再看“秒傳失敗”所有分片明明都在前端還是把幾百個分片重新傳了一遍。先把check接口返回的數(shù)組打印出來如果返回的index是字符串而前端用includes判斷時類型不匹配就會全部判斷成不存在。這是JavaScript弱類型最容易踩的坑之一要么后端返回數(shù)字要么前端parseInt之后再去includes。進度不準的問題多數(shù)出在進度計算公式上。整個上傳過程其實包含hash計算和上傳兩個階段很多人只算了上傳階段的片數(shù)百分比用戶從0%開始等hash算了半天進度一直是0體驗很差。我的習慣是給hash計算分配一個固定小百分比比如5%上傳階段占95%然后總體進度等于hash階段完成后5%再加上uploadedIndexes.length / totalChunkCount * 95。最后一個坑是關于端口和代理的。Vite開發(fā)服務器默認5173后端3000如果跨域或不走代理前端發(fā)出的/api請求會404。我建議demo里統(tǒng)一通過vite的proxy轉發(fā)生產環(huán)境則用nginx把/api反代到后端這是最不容易出問題的部署姿勢。6. 演示之外我把這套方案搬進真實項目的經驗demo寫完之后我在自己維護的一個網盤類小工具里把這套邏輯改了改上線遇到了一些demo里沒有體現(xiàn)的問題分享幾個方向你可以作為下一步擴展的參考。第一是取消和續(xù)傳的狀態(tài)管理。demo里暫停用一個布爾標志位搞定但真實場景用戶可能在上傳中刷新頁面、切走再回來前端需要把上傳任務持久化到localStorage甚至IndexedDB記錄文件hash、分片序號和進度。重新加載后先恢復任務列表再逐個調check接口確定真實進度。這一步不做用戶中途刷新一次前面?zhèn)鞯钠腿皝G了”心智雖然服務端物理上還在但前端不知道從哪里繼續(xù)。第二是Web Worker里跑hash。我在worker里維護了一個“取消計算”的信號主線程傳給worker或者直接調用worker.terminate()用戶取消上傳時能把hash計算立刻停下來。這一改動對體驗的提升非常明顯尤其面對10GB以上的文件hash計算可能要好幾分鐘。第三是服務端的整潔度。文件系統(tǒng)做斷點記錄在單機demo里很舒服但上線后最好把“分片狀態(tài)”抽到Redis緩存文件本體放對象存儲或者分布式文件系統(tǒng)合并操作交給后端異步任務隊列去跑而不是在HTTP請求里同步讀寫大文件。同步讀寫會導致請求一直掛著網關很快超時斷開合并卻還在后臺寫文件返回包用戶根本收不到。如果只是要一個能跑的DEMO照著上面的代碼敲一遍就夠了如果要把斷點續(xù)傳做成生產功能分片存儲、失敗重試、秒傳校驗、權限控制這幾個模塊都值得單獨花時間打磨。我現(xiàn)在回看這個項目最大的收獲不是某個API有多難而是“把大問題拆成小問題、再對小問題分別處理”這個思路在斷點續(xù)傳里體現(xiàn)得尤其明顯。真遇到大文件傳輸需求時先別急著找現(xiàn)成的上傳組件把文件分片、hash指紋、斷點記錄這三件事想清楚代碼自然就出來了。