戰(zhàn)指南：解決大文件傳輸難題，實(shí)現(xiàn)斷點(diǎn)續(xù)傳與秒傳)
1. 整車(chē)廠大附件到底有多大被附件拖垮的供應(yīng)商門(mén)戶(hù)去年我給一家汽車(chē)制造企業(yè)做供應(yīng)商門(mén)戶(hù)的附件模塊改造真正觸發(fā)這次改造的是一通來(lái)自工藝部門(mén)的電話。對(duì)方語(yǔ)氣很急一個(gè)3.5GB的焊裝線改造仿真視頻傳到73%斷了重傳一次到50%又崩了瀏覽器直接白屏再點(diǎn)上傳按鈕毫無(wú)反應(yīng)。這不是個(gè)例。整車(chē)廠和供應(yīng)商之間每天流轉(zhuǎn)的文件體積早就超出普通網(wǎng)頁(yè)上傳能承受的范疇。我翻了后臺(tái)日志把過(guò)去一個(gè)月上傳失敗的文件做了個(gè)統(tǒng)計(jì)發(fā)現(xiàn)超過(guò)1GB的文件失敗率高達(dá)四成失敗原因幾乎都是網(wǎng)絡(luò)中斷、請(qǐng)求超時(shí)、瀏覽器內(nèi)存溢出這老三樣。最夸張的一條記錄里同一個(gè)2.8GB的檢測(cè)報(bào)告被供應(yīng)商傳了11次才成功。1.1 一組真實(shí)的文件體量數(shù)據(jù)汽車(chē)制造場(chǎng)景里的大附件不是我們平時(shí)理解的幾百M(fèi)B而是以GB為單位的龐然大物。我整理了一下那家企業(yè)在供應(yīng)商門(mén)戶(hù)、研發(fā)協(xié)同平臺(tái)、質(zhì)量追溯系統(tǒng)里經(jīng)常出現(xiàn)的附件類(lèi)型大概是這么個(gè)量級(jí)文件類(lèi)型典型體量產(chǎn)生環(huán)節(jié)上傳方向CAD數(shù)模Catia/UG500MB - 3GB產(chǎn)品設(shè)計(jì)供應(yīng)商 → 主機(jī)廠焊裝線仿真視頻1GB - 6GB工藝驗(yàn)證供應(yīng)商 → 主機(jī)廠路試車(chē)載視頻500MB - 8GB質(zhì)量測(cè)試測(cè)試部門(mén)內(nèi)部PPAP整套提交包200MB - 1.5GB生產(chǎn)件批準(zhǔn)供應(yīng)商 → 主機(jī)廠BOM清單與檢測(cè)報(bào)告50MB - 800MB采購(gòu)與質(zhì)檢供應(yīng)商 → 主機(jī)廠這些文件有很多共同特征周期緊當(dāng)天必須交付網(wǎng)絡(luò)環(huán)境不可控供應(yīng)商那邊可能是跨國(guó)專(zhuān)線也可能是普通寬帶文件本身是企業(yè)核心數(shù)據(jù)不容丟失。1.2 為什么普通上傳方案在制造場(chǎng)景必然翻車(chē)很多人覺(jué)得大附件傳不上去是后端服務(wù)器或者帶寬的問(wèn)題其實(shí)第一道坎在瀏覽器。傳統(tǒng)的input typefile配合表單提交瀏覽器會(huì)先把整個(gè)文件讀進(jìn)內(nèi)存再發(fā)請(qǐng)求。一個(gè)3GB的文件先不說(shuō)用戶(hù)要等多久Chrome在32位系統(tǒng)下單進(jìn)程內(nèi)存上限都不夠用直接白屏太正常了。就算文件勉強(qiáng)讀進(jìn)去了一個(gè)POST請(qǐng)求把幾GB數(shù)據(jù)一次推給后端中間經(jīng)過(guò)Nginx、網(wǎng)關(guān)、應(yīng)用服務(wù)器任何一個(gè)環(huán)節(jié)的超時(shí)時(shí)間設(shè)置都會(huì)成為斷點(diǎn)。請(qǐng)求斷了就得從頭再來(lái)沒(méi)有任何挽回余地。汽車(chē)行業(yè)的供應(yīng)商網(wǎng)絡(luò)質(zhì)量參差不齊跨境傳輸時(shí)丟包率稍高大請(qǐng)求基本必?cái)?。這就引出分片上傳的核心思路不跟大文件正面硬剛把它切成幾十上百個(gè)小塊每個(gè)小塊獨(dú)立上傳。小塊傳輸天然抗網(wǎng)絡(luò)抖動(dòng)失敗只需要重傳那一個(gè)小塊而不是整個(gè)文件。加上并發(fā)控制、斷點(diǎn)續(xù)傳、秒傳校驗(yàn)才能保證幾個(gè)GB的文件在弱網(wǎng)環(huán)境下也能完整落到服務(wù)器。2. 分片上傳的核心邏輯把3.5GB拆成700份再逐個(gè)擊破分片上傳不是什么新概念早年網(wǎng)盤(pán)就是這么干的。但制造業(yè)門(mén)戶(hù)跟消費(fèi)級(jí)網(wǎng)盤(pán)不一樣它要考慮文件權(quán)限、審計(jì)、與工單系統(tǒng)的關(guān)聯(lián)以及供應(yīng)商和主機(jī)廠之間的網(wǎng)絡(luò)現(xiàn)實(shí)。下面我把這套邏輯拆開(kāi)講清楚理解了再去看源碼自己改起來(lái)才不慌。2.1 分片上傳的整體流程一次完整的分片上傳包含七個(gè)階段前端讀取文件計(jì)算MD5指紋調(diào)用初始化接口把文件名、大小、總分片數(shù)、MD5交給后端拿到文件唯一ID后端拿到MD5后先查重如果庫(kù)里已有相同指紋的文件直接返回秒傳完成不走后續(xù)流程前端按固定大小切分文件生成分片序號(hào)前端把分片并發(fā)上傳每傳完一片后端落盤(pán)并記錄所有分片傳完后前端調(diào)用合并接口后端把臨時(shí)分片按順序拼成完整文件校驗(yàn)合并后的文件MD5核對(duì)大小標(biāo)記上傳完成。在這個(gè)流程里分片只是手段不是目的。真正要解決的是兩個(gè)問(wèn)題單次請(qǐng)求體量可控以及失敗后最小成本重試。2.2 秒傳與斷點(diǎn)續(xù)傳MD5在這里的真正作用很多人以為MD5是用來(lái)校驗(yàn)文件完整性的在分片上傳里它的首要作用是去重。供應(yīng)商第二次提交同一個(gè)檢測(cè)報(bào)告前端算出MD5以后后端一查指紋一樣直接告訴前端不用傳了文件已經(jīng)有了上傳進(jìn)度條一秒拉滿。汽車(chē)行業(yè)里同一份PPAP包改來(lái)改去、反復(fù)提交的情況太多了這一招能省掉大量無(wú)效傳輸。斷點(diǎn)續(xù)傳的邏輯更直接。前端每次開(kāi)始上傳前調(diào)用一次查詢(xún)已上傳分片接口后端返回已落盤(pán)的分片序號(hào)列表前端只把缺失的分片補(bǔ)傳。這樣哪怕傳了一半電腦斷電、瀏覽器崩潰重新打開(kāi)頁(yè)面選同一個(gè)文件秒進(jìn)續(xù)傳狀態(tài)而不是從頭再來(lái)。2.3 并發(fā)數(shù)和分片大小的選擇邏輯分片大小和并發(fā)數(shù)是整個(gè)方案里最需要權(quán)衡的兩個(gè)參數(shù)。切得太小分片數(shù)量暴增請(qǐng)求次數(shù)多了后端壓力大而且每個(gè)請(qǐng)求都有TCP握手和HTTP頭開(kāi)銷(xiāo)總耗時(shí)反而變長(zhǎng)。切得太大單個(gè)請(qǐng)求又回到了大請(qǐng)求容易斷的老問(wèn)題。我在這套系統(tǒng)里用的是5MB一片并發(fā)3個(gè)請(qǐng)求。算一下3.5GB 3584MB正好切714片默認(rèn)帶寬下并發(fā)3路每片獨(dú)立確認(rèn)整體進(jìn)度只增不減。并發(fā)數(shù)為什么是3而不是10因?yàn)闉g覽器對(duì)同一域名的TCP連接默認(rèn)限制是6個(gè)如果前端還有其他接口要調(diào)用占滿連接池會(huì)導(dǎo)致頁(yè)面其他請(qǐng)求排隊(duì)等待。留3個(gè)連接給普通接口調(diào)用上傳占3個(gè)是綜合體驗(yàn)最穩(wěn)的配比。3. 前端源碼實(shí)現(xiàn)切片、并發(fā)池、進(jìn)度與重試前端這部分我直接貼核心代碼基于原生JavaScript實(shí)現(xiàn)不依賴(lài)框架你把它接進(jìn)Vue、React或者單純的jQuery頁(yè)面都能用。先說(shuō)明一下整體結(jié)構(gòu)File切片用File.slice()MD5計(jì)算用SparkedMD5庫(kù)并發(fā)控制自己寫(xiě)一個(gè)簡(jiǎn)單的請(qǐng)求池不用第三方庫(kù)方便理解也方便改。3.1 文件的讀取與分片切片本身特別簡(jiǎn)單但要注意分片序號(hào)必須補(bǔ)零。后面合并時(shí)要按字典序排序如果不補(bǔ)零10會(huì)排在2前面文件順序就亂了。const CHUNK_SIZE 5 * 1024 * 1024; // 5MB function createChunks(file) { const count Math.ceil(file.size / CHUNK_SIZE); const chunks []; for (let i 0; i count; i) { const start i * CHUNK_SIZE; const end Math.min(start CHUNK_SIZE, file.size); chunks.push({ index: i, indexStr: String(i).padStart(6, 0), // 補(bǔ)零保證排序正確 blob: file.slice(start, end) }); } return chunks; }padStart(6, 0)這行是關(guān)鍵別省。700多片最多三位數(shù)補(bǔ)6位是為了以后超大文件擴(kuò)展時(shí)不用改代碼。切完以后每個(gè)分片就是一個(gè)獨(dú)立的小Blob對(duì)象5MB的小塊發(fā)給后端資源占用完全可控。3.2 MD5指紋計(jì)算用Web Worker避免卡死頁(yè)面計(jì)算3.5GB文件的MD5不是瞬間的事在純前端主線程里算會(huì)導(dǎo)致頁(yè)面卡頓用戶(hù)以為瀏覽器死了。解決方案是把計(jì)算丟到Web Worker里。我用的是SparkMD5的增量計(jì)算模式逐片讀取文件邊讀邊算不把整個(gè)文件加載進(jìn)內(nèi)存。// worker.js importScripts(spark-md5.min.js); self.onmessage function(e) { const file e.data.file; const chunkSize e.data.chunkSize; const spark new SparkMD5.ArrayBuffer(); let offset 0; const total file.size; function readNext() { if (offset total) { const hex spark.end(); self.postMessage({ type: done, hex }); return; } const blob file.slice(offset, Math.min(offset chunkSize, total)); const reader new FileReader(); reader.onload function(event) { spark.append(event.target.result); offset event.target.result.byteLength; // 每算完一塊匯報(bào)一次進(jìn)度 self.postMessage({ type: progress, percent: Math.round(offset / total * 100) }); readNext(); }; reader.readAsArrayBuffer(blob); } readNext(); };主線程那邊只需要function calcFileMD5(file) { return new Promise((resolve, reject) { const worker new Worker(worker.js); worker.postMessage({ file, chunkSize: CHUNK_SIZE }); worker.onmessage (e) { if (e.data.type progress) { updateHashProgress(e.data.percent); // 展示正在校驗(yàn)文件提示條 } else if (e.data.type done) { worker.terminate(); resolve(e.data.hex); } }; worker.onerror reject; }); }3GB的文件用這種方式算MD5大概需要20到40秒取決于CPU性能。體驗(yàn)上要給用戶(hù)明確反饋不然用戶(hù)以為卡死了直接把頁(yè)面關(guān)了。3.3 請(qǐng)求并發(fā)池的實(shí)現(xiàn)并發(fā)池是前端控制上傳節(jié)奏的核心。它的作用是同時(shí)最多跑3個(gè)上傳請(qǐng)求一個(gè)完成了馬上從待上傳隊(duì)列里拿下一個(gè)補(bǔ)上。這樣不會(huì)把瀏覽器連接池占滿也能保證進(jìn)度條平滑前移。async function uploadChunks(chunks, fileId, onProgress) { const concurrency 3; const queue [...chunks]; const results new Array(chunks.length); let completed 0; async function worker() { while (queue.length 0) { const chunk queue.shift(); const formData new FormData(); formData.append(fileId, fileId); formData.append(chunkIndex, chunk.indexStr); formData.append(chunk, chunk.blob); try { await axios.post(/api/upload/chunk, formData, { timeout: 120000, // 單分片超時(shí)2分鐘 onUploadProgress: () {} }); results[chunk.index] true; completed; onProgress(Math.round(completed / chunks.length * 100)); } catch (err) { // 單片失敗重試3次仍然失敗就中斷并拋出 await retryUpload(chunk, fileId, 3); completed; onProgress(Math.round(completed / chunks.length * 100)); } } } const workers []; for (let i 0; i concurrency; i) { workers.push(worker()); } await Promise.all(workers); return results; }這里注意一個(gè)細(xì)節(jié)單分片超時(shí)設(shè)置成了2分鐘。5MB的分片哪怕是撥號(hào)網(wǎng)絡(luò)也不該傳2分鐘設(shè)置這個(gè)值的意義是防止某個(gè)請(qǐng)求卡死導(dǎo)致并發(fā)池里的worker永遠(yuǎn)不釋放拖慢整個(gè)隊(duì)列。超時(shí)后主動(dòng)失敗觸發(fā)重試邏輯新的請(qǐng)求會(huì)重新加入排隊(duì)。3.4 進(jìn)度的精確計(jì)算進(jìn)度條不應(yīng)該是某一片正在傳就顯示那一小段的百分比而是以已成功落盤(pán)的分片數(shù)量為準(zhǔn)。每成功一片進(jìn)度 成功片數(shù) / 總分片數(shù)。這種計(jì)算方式不受單片傳輸速度波動(dòng)影響用戶(hù)看到的進(jìn)度條是穩(wěn)定向前的。有兩點(diǎn)要特別提示前端開(kāi)發(fā)注意一是進(jìn)度到達(dá)100%不代表上傳完成后端還要合并需要把狀態(tài)切成服務(wù)器合并中二是進(jìn)度條卡在99%一定不要慌張那是因?yàn)楹喜㈦A段沒(méi)有獨(dú)立的進(jìn)度反饋等后端合并完成就好了。如果你想讓體驗(yàn)更好可以在合并接口被調(diào)用后輪詢(xún)一個(gè)合并狀態(tài)接口展示真實(shí)的合并進(jìn)度后面我會(huì)講到后端如何配合。4. 后端源碼實(shí)現(xiàn)分片接收、索引校驗(yàn)與安全合并后端我用Node.js Express來(lái)寫(xiě)因?yàn)檫@在一線環(huán)境里最容易快速部署和二次開(kāi)發(fā)。如果你所在的企業(yè)后端是Java或.NET邏輯完全一致只需要把文件操作、接口返回?fù)Q成對(duì)應(yīng)的方言即可。目錄結(jié)構(gòu)我先給出來(lái)upload-service/ ├── app.js ├── config.js ├── uploads/ │ ├── tmp/ # 分片臨時(shí)目錄 │ └── files/ # 合并后的正式文件 └── routes/ ├── init.js ├── chunk.js ├── query.js └── merge.js4.1 初始化接口拿到文件唯一憑證前端算完MD5后調(diào)用這個(gè)接口后端返回fileId這個(gè)ID貫穿整個(gè)上傳生命周期。// routes/init.js const crypto require(crypto); const fs require(fs); const path require(path); const { tmpDir } require(../config); router.post(/init, async (req, res) { const { fileName, fileSize, chunkCount, md5 } req.body; // 1. 秒傳檢查MD5已存在則直接返回已完成 const exists await findFileByMd5(md5); if (exists) { return res.json({ code: 0, data: { fileId: exists.fileId, uploaded: true, message: 文件已存在秒傳成功 } }); } // 2. 斷點(diǎn)續(xù)傳檢查如果有未完成的上傳記錄則復(fù)用 const existing await findUploadRecord(md5); if (existing) { return res.json({ code: 0, data: { fileId: existing.fileId, uploaded: false } }); } // 3. 新建上傳記錄 const fileId crypto.randomUUID().replace(/-/g, ); const task { fileId, fileName, fileSize, chunkCount, md5, status: uploading, uploadedChunks: [], createTime: Date.now() }; // 落庫(kù)同時(shí)創(chuàng)建臨時(shí)目錄 await saveUploadRecord(task); fs.mkdirSync(path.join(tmpDir, fileId), { recursive: true }); res.json({ code: 0, data: { fileId, uploaded: false } }); });秒傳這個(gè)分支一定要做在初始化階段而不是合并階段這樣能省掉整個(gè)上傳過(guò)程的帶寬和計(jì)算資源。4.2 分片寫(xiě)入接口與完整性校驗(yàn)分片接口接收的是multipart/form-data格式前端每次提交一片后端把這片追加寫(xiě)入臨時(shí)目錄。這里我做兩個(gè)校驗(yàn)分片序號(hào)必須落在合法范圍內(nèi)分片大小不能超過(guò)約定上限防止惡意請(qǐng)求寫(xiě)壞磁盤(pán)。// routes/chunk.js const multer require(multer); const fs require(fs); const path require(path); router.post(/chunk, multer().single(chunk), async (req, res) { const { fileId, chunkIndex } req.body; const chunkIndexNum parseInt(chunkIndex, 10); const record await findUploadRecord(fileId); if (!record) { return res.status(404).json({ code: 404, message: 上傳記錄不存在 }); } if (chunkIndexNum 0 || chunkIndexNum record.chunkCount) { return res.status(400).json({ code: 400, message: 非法分片序號(hào) }); } if (req.file.size 5 * 1024 * 1024 1024) { return res.status(400).json({ code: 400, message: 分片大小超限 }); } const chunkPath path.join(tmpDir, fileId, ${chunkIndex}.part); fs.writeFileSync(chunkPath, req.file.buffer); await markChunkUploaded(fileId, chunkIndexNum); res.json({ code: 0, message: 分片寫(xiě)入成功 }); });分片文件名用純數(shù)字加.part后綴方便合并時(shí)排序。這里為了方便直接用了writeFileSync因?yàn)閱蝹€(gè)分片只有5MB內(nèi)存壓力不大。如果你把分片調(diào)到20MB以上建議改成流式寫(xiě)入避免多并發(fā)時(shí)內(nèi)存暴漲。這里還涉及一個(gè)容易被忽略的點(diǎn)服務(wù)端必須記錄已上傳分片否則斷點(diǎn)續(xù)傳無(wú)從談起。我在markChunkUploaded里做的是更新數(shù)據(jù)庫(kù)記錄把分片序號(hào)追加到一個(gè)數(shù)組字段里。更穩(wěn)妥的方案是一個(gè)分片一條記錄用獨(dú)立的表存儲(chǔ)這樣查詢(xún)已上傳分片時(shí)可以直接用索引。4.3 合并接口流式合并而不是內(nèi)存拼接合并是整個(gè)后端最容易翻車(chē)的地方。新手最容易犯的錯(cuò)誤是用Buffer.concat()把所有分片拼起來(lái)再寫(xiě)文件幾個(gè)GB的文件直接內(nèi)存溢出。正確做法是用Node.js的createReadStream和createWriteStream流水線式合并每次只讀寫(xiě)一小塊。// routes/merge.js const fs require(fs); const path require(path); const { Transform } require(stream); router.post(/merge, async (req, res) { const { fileId } req.body; const record await findUploadRecord(fileId); const uploadedCount record.uploadedChunks.length; if (uploadedCount ! record.chunkCount) { return res.status(400).json({ code: 400, message: 尚有分片未上傳還需${record.chunkCount - uploadedCount}片 }); } const destPath path.join(filesDir, record.fileName); const writeStream fs.createWriteStream(destPath); // 按分片序號(hào)排序 const sortedChunks Array.from({ length: record.chunkCount }, (_, i) i); async function appendChunk(index) { if (index sortedChunks.length) { writeStream.end(); return; } const chunkPath path.join(tmpDir, fileId, ${sortedChunks[index]}.part); const readStream fs.createReadStream(chunkPath); readStream.on(end, () appendChunk(index 1)); readStream.on(error, (err) { writeStream.destroy(); res.status(500).json({ code: 500, message: 合并失敗分片${index}讀取出錯(cuò) }); }); readStream.pipe(writeStream, { end: false }); } appendChunk(0); });合并這種寫(xiě)法本質(zhì)上就是挨個(gè)把分片文件接起來(lái)像拼水管一樣。這里每個(gè)分片的讀取是流式的內(nèi)存占用始終只有幾百KB不會(huì)因?yàn)槲募蠖鲩L(zhǎng)。合并完成之后還要做一次完整的校驗(yàn)計(jì)算合并后文件的MD5與初始化時(shí)的MD5比對(duì)。一致才更新上傳狀態(tài)為完成。這一步不能省網(wǎng)絡(luò)傳輸環(huán)節(jié)雖然每個(gè)分片的TCP校驗(yàn)都過(guò)了一遍但拼接順序、分片內(nèi)容丟失這類(lèi)邏輯錯(cuò)誤只有整體MD5才能抓出來(lái)。4.4 臨時(shí)分片的生命周期管理合并完成后臨時(shí)分片目錄要及時(shí)清理。我是用一個(gè)定時(shí)任務(wù)每小時(shí)掃描一次臨時(shí)目錄清理兩類(lèi)文件合并完成后遺留的分片以及超過(guò)24小時(shí)沒(méi)有新分片的半截上傳記錄。這里有個(gè)業(yè)務(wù)考量保留24小時(shí)是為了給斷點(diǎn)續(xù)傳留余地用戶(hù)今天傳了一半下班了明天還能續(xù)傳。超過(guò)24小時(shí)基本可以判定是放棄上傳了僵尸分片會(huì)占據(jù)硬盤(pán)空間必須清掉。清理時(shí)還要同步清理數(shù)據(jù)庫(kù)里的上傳記錄避免記錄越積越多拖慢查詢(xún)。5. 讓3.5GB真正傳完的可靠性設(shè)計(jì)代碼能跑通是一回事真正讓幾個(gè)GB的文件在各種惡劣網(wǎng)絡(luò)環(huán)境下都能傳完是另一回事。我在這里把上線過(guò)程中驗(yàn)證過(guò)的可靠性機(jī)制完整列出來(lái)。這些機(jī)制單獨(dú)看都是小改動(dòng)合在一起才是3.5GB一次傳完的底氣。5.1 網(wǎng)絡(luò)層超時(shí)、重試與并發(fā)降級(jí)分片上傳最大的好處是單次請(qǐng)求變小了但小請(qǐng)求同樣會(huì)遇到超時(shí)和斷連。我的處理策略是三層兜底單分片請(qǐng)求超時(shí)120秒超時(shí)就中斷中斷后的分片自動(dòng)重試最多3次每次間隔指數(shù)退避2秒、4秒、8秒連續(xù)3次失敗后并發(fā)數(shù)從3降為1用單線程繼續(xù)傳這樣能避免在網(wǎng)絡(luò)質(zhì)量極差時(shí)多個(gè)并發(fā)請(qǐng)求互相爭(zhēng)搶帶寬反而一個(gè)都傳不完。這層邏輯寫(xiě)在前端并發(fā)池的worker里后端不需要感知。后端要做的反而是把超時(shí)時(shí)間設(shè)得盡量寬松一些避免因?yàn)榫W(wǎng)關(guān)代理的默認(rèn)超時(shí)把慢速請(qǐng)求提前掐斷。如果你們Nginx配了proxy_read_timeout建議調(diào)到180秒以上。5.2 服務(wù)端崩潰后如何續(xù)傳服務(wù)端重啟、磁盤(pán)滿、進(jìn)程被殺這些故障都會(huì)中斷上傳過(guò)程。但只要分片已經(jīng)落盤(pán)、上傳記錄寫(xiě)進(jìn)了數(shù)據(jù)庫(kù)前端感知到連接斷開(kāi)后重新走一遍初始化流程后端發(fā)現(xiàn)同名MD5的上傳記錄還在返回同一個(gè)fileId前端再查詢(xún)已上傳分片就能精準(zhǔn)定位到中斷位置。這套機(jī)制的關(guān)鍵在于每個(gè)分片寫(xiě)入必須是原子操作。也就是要么完全寫(xiě)成功要么完全不寫(xiě)。writeFileSync天然具備這個(gè)特性只要不出現(xiàn)寫(xiě)一半進(jìn)程被殺的情況。為了更穩(wěn)我建議分片文件名里包含分片序號(hào)寫(xiě)入時(shí)先寫(xiě)臨時(shí)名再rename成正式名rename是原子操作更安全。5.3 頁(yè)面層關(guān)閉標(biāo)簽頁(yè)后的恢復(fù)方案用戶(hù)傳了一半關(guān)了標(biāo)簽頁(yè)再回來(lái)發(fā)現(xiàn)進(jìn)度條歸零會(huì)非常崩潰。前端要做的是把上傳狀態(tài)持久化到localStorage包含fileId、文件名、文件大小、MD5、總分片數(shù)。用戶(hù)重新選擇同一個(gè)文件時(shí)先查localStorage發(fā)現(xiàn)相同大小的文件且MD5一致直接調(diào)用后端查詢(xún)接口恢復(fù)進(jìn)度條。function saveUploadTask(file, fileId, md5) { localStorage.setItem(uploadTask, JSON.stringify({ fileName: file.name, fileSize: file.size, fileId, md5, uploadTime: Date.now() })); } async function resumeUploadIfNeeded(file) { const saved localStorage.getItem(uploadTask); if (!saved) return null; const task JSON.parse(saved); if (task.fileName ! file.name || task.fileSize ! file.size) return null; const { data } await axios.post(/api/upload/query, { fileId: task.fileId }); // data.uploadedChunks: 已上傳分片序號(hào)數(shù)組 return { task, uploadedChunks: data.uploadedChunks }; }注意localStorage有5MB大小限制這里只保存描述信息不保存文件本身不會(huì)越界。5.4 磁盤(pán)與存儲(chǔ)合并前的最后一公里后端存儲(chǔ)是整個(gè)鏈路里最容易靜默崩潰的一環(huán)。分片寫(xiě)入階段臨時(shí)目錄可能迅速膨脹幾個(gè)大文件同時(shí)在傳時(shí)磁盤(pán)占用是幾倍于最終文件大小的。我遇到過(guò)生產(chǎn)環(huán)境磁盤(pán)滿導(dǎo)致分片寫(xiě)不進(jìn)去前端一直報(bào)網(wǎng)絡(luò)錯(cuò)誤排查半天才發(fā)現(xiàn)是磁盤(pán)問(wèn)題。建議從第一天起就加三樣?xùn)|西磁盤(pán)剩余空間監(jiān)控低于10%告警、臨時(shí)目錄的獨(dú)立掛載盤(pán)與系統(tǒng)盤(pán)分離避免寫(xiě)滿系統(tǒng)盤(pán)、以及合并完成后的文件歸檔策略正式文件立即轉(zhuǎn)存到獨(dú)立存儲(chǔ)或?qū)ο蟠鎯?chǔ)應(yīng)用服務(wù)器只保留最近幾天的文件。6. 上線后踩過(guò)的坑從413到文件損壞的完整排查鏈路方案上線兩周問(wèn)題一個(gè)接一個(gè)冒出來(lái)。很多坑在開(kāi)發(fā)環(huán)境根本測(cè)不出來(lái)只有真正跑到供應(yīng)商的真實(shí)網(wǎng)絡(luò)和生產(chǎn)環(huán)境里才暴露。我把這幾個(gè)坑按排查鏈路寫(xiě)出來(lái)你照著這個(gè)順序排查能省大量時(shí)間。6.1 第一個(gè)坑Nginx默認(rèn)限制導(dǎo)致的413上線當(dāng)天就有供應(yīng)商反饋小文件能傳大文件一點(diǎn)上傳就報(bào)413 Request Entity Too Large。我第一時(shí)間想到的不是應(yīng)用代碼而是Nginx的client_max_body_size默認(rèn)值是1MB。分片雖然是5MB但這個(gè)限制作用于整個(gè)請(qǐng)求體大小所以5MB的分片請(qǐng)求也會(huì)被Nginx擋下來(lái)。排查鏈路很簡(jiǎn)單先看瀏覽器開(kāi)發(fā)者工具里的網(wǎng)絡(luò)請(qǐng)求發(fā)現(xiàn)POST /api/upload/chunk返回413再確認(rèn)請(qǐng)求體確實(shí)約5MB最后登錄服務(wù)器檢查Nginx配置。修復(fù)也直接server { client_max_body_size 10m; client_body_buffer_size 128k; proxy_request_buffering off; }為什么加proxy_request_buffering off因?yàn)槟J(rèn)開(kāi)啟時(shí)Nginx會(huì)把完整請(qǐng)求體緩沖到磁盤(pán)再轉(zhuǎn)發(fā)給后端分片這種流式提交場(chǎng)景等緩沖完再轉(zhuǎn)發(fā)會(huì)帶來(lái)無(wú)謂的延遲和磁盤(pán)IO。關(guān)閉后直接流式轉(zhuǎn)發(fā)給Node進(jìn)程。注意這里10m上限要大于分片大小的實(shí)際值留出multipart格式的額外開(kāi)銷(xiāo)余量。6.2 第二個(gè)坑負(fù)載均衡把分片拆到了兩臺(tái)機(jī)器這個(gè)是排查時(shí)間最長(zhǎng)的坑。供應(yīng)商反饋文件傳到一半報(bào)錯(cuò)查看后端日志發(fā)現(xiàn)有的分片寫(xiě)入成功有的直接404。仔細(xì)檢查后發(fā)現(xiàn)問(wèn)題出在部署架構(gòu)上服務(wù)跑在負(fù)載均衡后面的兩臺(tái)機(jī)器上同一個(gè)上傳任務(wù)的分片A請(qǐng)求被負(fù)載均衡轉(zhuǎn)發(fā)到節(jié)點(diǎn)1分片B請(qǐng)求被轉(zhuǎn)發(fā)到節(jié)點(diǎn)2兩臺(tái)機(jī)器各自的磁盤(pán)上只有一半分片合并接口在所有節(jié)點(diǎn)上都找不到完整數(shù)據(jù)。解決方案有兩種我選了比較簡(jiǎn)單的那種做應(yīng)用層會(huì)話保持。在負(fù)載均衡配置里按fileId做哈希路由保證同一個(gè)fileId的所有分片請(qǐng)求都落到同一個(gè)節(jié)點(diǎn)。更徹底的方案是把臨時(shí)目錄掛到共享存儲(chǔ)上但那個(gè)改動(dòng)太大不是緊急情況不值得動(dòng)。如果你用的是阿里云SLB或Nginx upstream有個(gè)更穩(wěn)妥的處理方式分片接口不依賴(lài)會(huì)話保持而是把分片數(shù)據(jù)直接寫(xiě)到共享的存儲(chǔ)層比如NFS或?qū)ο蟠鎯?chǔ)各節(jié)點(diǎn)讀取同一份數(shù)據(jù)。這屬于一次性投入以后擴(kuò)容也方便。6.3 第三個(gè)坑分片排序的字典序陷阱這個(gè)坑特別隱蔽而且只在文件超過(guò)100片時(shí)出現(xiàn)。某供應(yīng)商傳一個(gè)600MB的壓縮包合并后文件損壞解壓報(bào)錯(cuò)。我一開(kāi)始以為是分片丟失數(shù)了一遍數(shù)量是齊的又懷疑是某個(gè)分片內(nèi)容損壞但MD5對(duì)不上。最后把合并后的文件按順序?qū)Ρ仍嘉募l(fā)現(xiàn)有些數(shù)據(jù)塊順序反了。原因就是我在前端只用了String(i)做序號(hào)沒(méi)補(bǔ)零后端合并時(shí)用字符串排序10排到了2前面。雖然前端createChunks里已經(jīng)修正了這個(gè)問(wèn)題但當(dāng)時(shí)后端合并邏輯里自己也重新組裝了一次分片列表用的還是普通數(shù)組順序沒(méi)按補(bǔ)零后的字符串排。教訓(xùn)有兩條一是前端序號(hào)的padStart(6,0)必須做二是后端在合并前要把分片序號(hào)轉(zhuǎn)成數(shù)字再排序不要用字符串。兩邊都按數(shù)字排序這個(gè)坑就徹底解決了。6.4 第四個(gè)坑合并進(jìn)度為零的假卡死進(jìn)度條走到100%接口遲遲不返回用戶(hù)端看到的是上傳完成但處理中一直轉(zhuǎn)圈。排查后發(fā)現(xiàn)是合并時(shí)沒(méi)有給前端進(jìn)度反饋大文件合并要幾十秒用戶(hù)沒(méi)有任何提示體驗(yàn)上就是卡死了。我的解決辦法是把合并改成長(zhǎng)輪詢(xún)后端合并時(shí)把進(jìn)度寫(xiě)進(jìn)Redis前端啟動(dòng)合并后每2秒拉一次合并狀態(tài)接口展示單獨(dú)的合并進(jìn)度條。合并完成后前端彈出結(jié)果提示同時(shí)把localStorage里的上傳任務(wù)清掉。順帶還發(fā)現(xiàn)一個(gè)細(xì)節(jié)合并狀態(tài)接口要設(shè)置合理的緩存頭否則前端每次拉取都會(huì)走完整HTTP鏈路浪費(fèi)資源。我用的是Cache-Control: no-store因?yàn)闋顟B(tài)是實(shí)時(shí)變化的絕不能緩存。最后一點(diǎn)個(gè)人體會(huì)整套方案從設(shè)計(jì)到上線用了一個(gè)多月跑通核心流程只用了一周剩余時(shí)間幾乎都花在踩坑和加固上。如果讓我給正準(zhǔn)備做大附件上傳的人一個(gè)建議那就是不要沉迷于一次性把代碼寫(xiě)完美先把主流程跑通然后把網(wǎng)絡(luò)故障當(dāng)成必然事件來(lái)設(shè)計(jì)。大附件上傳的本質(zhì)不是上傳而是對(duì)抗不確定性——網(wǎng)絡(luò)會(huì)斷、服務(wù)器會(huì)重啟、用戶(hù)會(huì)中途關(guān)瀏覽器、磁盤(pán)會(huì)滿、代理會(huì)超時(shí)。把這些場(chǎng)景先想清楚代碼怎么寫(xiě)都對(duì)。另外有一件小事值得提汽車(chē)行業(yè)對(duì)文件的合規(guī)要求比一般行業(yè)嚴(yán)涉及供應(yīng)商提交的文件我們后來(lái)給每個(gè)分片加了上傳人的身份信息記錄合并完成后生成完整的審計(jì)日志。雖然這跟分片上傳本身關(guān)系不大但如果你做的系統(tǒng)要過(guò)體系審核最好提前把這條鏈路設(shè)計(jì)進(jìn)去別等審核組來(lái)查的時(shí)候再補(bǔ)那時(shí)候數(shù)據(jù)早就不全了。這套方案的源碼我手上還留著完整版包括前端組件化封裝、后端分片清理腳本的定時(shí)任務(wù)實(shí)現(xiàn)以及合并進(jìn)度的輪詢(xún)邏輯。篇幅原因沒(méi)法全部貼出來(lái)如果你在實(shí)際落地時(shí)遇到具體問(wèn)題歡迎在評(píng)論區(qū)帶上你的報(bào)錯(cuò)信息和技術(shù)棧我可以針對(duì)性地給出解釋。 分片上傳實(shí)戰(zhàn)指南：解決大文件傳輸難題，實(shí)現(xiàn)斷點(diǎn)續(xù)傳與秒傳
1. 整車(chē)廠大附件到底有多大被附件拖垮的供應(yīng)商門(mén)戶(hù)去年我給一家汽車(chē)制造企業(yè)做供應(yīng)商門(mén)戶(hù)的附件模塊改造真正觸發(fā)這次改造的是一通來(lái)自工藝部門(mén)的電話。對(duì)方語(yǔ)氣很急一個(gè)3.5GB的焊裝線改造仿真視頻傳到73%斷了重傳一次到50%又崩了瀏覽器直接白屏再點(diǎn)上傳按鈕毫無(wú)反應(yīng)。這不是個(gè)例。整車(chē)廠和供應(yīng)商之間每天流轉(zhuǎn)的文件體積早就超出普通網(wǎng)頁(yè)上傳能承受的范疇。我翻了后臺(tái)日志把過(guò)去一個(gè)月上傳失敗的文件做了個(gè)統(tǒng)計(jì)發(fā)現(xiàn)超過(guò)1GB的文件失敗率高達(dá)四成失敗原因幾乎都是網(wǎng)絡(luò)中斷、請(qǐng)求超時(shí)、瀏覽器內(nèi)存溢出這老三樣。最夸張的一條記錄里同一個(gè)2.8GB的檢測(cè)報(bào)告被供應(yīng)商傳了11次才成功。1.1 一組真實(shí)的文件體量數(shù)據(jù)汽車(chē)制造場(chǎng)景里的大附件不是我們平時(shí)理解的幾百M(fèi)B而是以GB為單位的龐然大物。我整理了一下那家企業(yè)在供應(yīng)商門(mén)戶(hù)、研發(fā)協(xié)同平臺(tái)、質(zhì)量追溯系統(tǒng)里經(jīng)常出現(xiàn)的附件類(lèi)型大概是這么個(gè)量級(jí)文件類(lèi)型典型體量產(chǎn)生環(huán)節(jié)上傳方向CAD數(shù)模Catia/UG500MB - 3GB產(chǎn)品設(shè)計(jì)供應(yīng)商 → 主機(jī)廠焊裝線仿真視頻1GB - 6GB工藝驗(yàn)證供應(yīng)商 → 主機(jī)廠路試車(chē)載視頻500MB - 8GB質(zhì)量測(cè)試測(cè)試部門(mén)內(nèi)部PPAP整套提交包200MB - 1.5GB生產(chǎn)件批準(zhǔn)供應(yīng)商 → 主機(jī)廠BOM清單與檢測(cè)報(bào)告50MB - 800MB采購(gòu)與質(zhì)檢供應(yīng)商 → 主機(jī)廠這些文件有很多共同特征周期緊當(dāng)天必須交付網(wǎng)絡(luò)環(huán)境不可控供應(yīng)商那邊可能是跨國(guó)專(zhuān)線也可能是普通寬帶文件本身是企業(yè)核心數(shù)據(jù)不容丟失。1.2 為什么普通上傳方案在制造場(chǎng)景必然翻車(chē)很多人覺(jué)得大附件傳不上去是后端服務(wù)器或者帶寬的問(wèn)題其實(shí)第一道坎在瀏覽器。傳統(tǒng)的input typefile配合表單提交瀏覽器會(huì)先把整個(gè)文件讀進(jìn)內(nèi)存再發(fā)請(qǐng)求。一個(gè)3GB的文件先不說(shuō)用戶(hù)要等多久Chrome在32位系統(tǒng)下單進(jìn)程內(nèi)存上限都不夠用直接白屏太正常了。就算文件勉強(qiáng)讀進(jìn)去了一個(gè)POST請(qǐng)求把幾GB數(shù)據(jù)一次推給后端中間經(jīng)過(guò)Nginx、網(wǎng)關(guān)、應(yīng)用服務(wù)器任何一個(gè)環(huán)節(jié)的超時(shí)時(shí)間設(shè)置都會(huì)成為斷點(diǎn)。請(qǐng)求斷了就得從頭再來(lái)沒(méi)有任何挽回余地。汽車(chē)行業(yè)的供應(yīng)商網(wǎng)絡(luò)質(zhì)量參差不齊跨境傳輸時(shí)丟包率稍高大請(qǐng)求基本必?cái)?。這就引出分片上傳的核心思路不跟大文件正面硬剛把它切成幾十上百個(gè)小塊每個(gè)小塊獨(dú)立上傳。小塊傳輸天然抗網(wǎng)絡(luò)抖動(dòng)失敗只需要重傳那一個(gè)小塊而不是整個(gè)文件。加上并發(fā)控制、斷點(diǎn)續(xù)傳、秒傳校驗(yàn)才能保證幾個(gè)GB的文件在弱網(wǎng)環(huán)境下也能完整落到服務(wù)器。2. 分片上傳的核心邏輯把3.5GB拆成700份再逐個(gè)擊破分片上傳不是什么新概念早年網(wǎng)盤(pán)就是這么干的。但制造業(yè)門(mén)戶(hù)跟消費(fèi)級(jí)網(wǎng)盤(pán)不一樣它要考慮文件權(quán)限、審計(jì)、與工單系統(tǒng)的關(guān)聯(lián)以及供應(yīng)商和主機(jī)廠之間的網(wǎng)絡(luò)現(xiàn)實(shí)。下面我把這套邏輯拆開(kāi)講清楚理解了再去看源碼自己改起來(lái)才不慌。2.1 分片上傳的整體流程一次完整的分片上傳包含七個(gè)階段前端讀取文件計(jì)算MD5指紋調(diào)用初始化接口把文件名、大小、總分片數(shù)、MD5交給后端拿到文件唯一ID后端拿到MD5后先查重如果庫(kù)里已有相同指紋的文件直接返回秒傳完成不走后續(xù)流程前端按固定大小切分文件生成分片序號(hào)前端把分片并發(fā)上傳每傳完一片后端落盤(pán)并記錄所有分片傳完后前端調(diào)用合并接口后端把臨時(shí)分片按順序拼成完整文件校驗(yàn)合并后的文件MD5核對(duì)大小標(biāo)記上傳完成。在這個(gè)流程里分片只是手段不是目的。真正要解決的是兩個(gè)問(wèn)題單次請(qǐng)求體量可控以及失敗后最小成本重試。2.2 秒傳與斷點(diǎn)續(xù)傳MD5在這里的真正作用很多人以為MD5是用來(lái)校驗(yàn)文件完整性的在分片上傳里它的首要作用是去重。供應(yīng)商第二次提交同一個(gè)檢測(cè)報(bào)告前端算出MD5以后后端一查指紋一樣直接告訴前端不用傳了文件已經(jīng)有了上傳進(jìn)度條一秒拉滿。汽車(chē)行業(yè)里同一份PPAP包改來(lái)改去、反復(fù)提交的情況太多了這一招能省掉大量無(wú)效傳輸。斷點(diǎn)續(xù)傳的邏輯更直接。前端每次開(kāi)始上傳前調(diào)用一次查詢(xún)已上傳分片接口后端返回已落盤(pán)的分片序號(hào)列表前端只把缺失的分片補(bǔ)傳。這樣哪怕傳了一半電腦斷電、瀏覽器崩潰重新打開(kāi)頁(yè)面選同一個(gè)文件秒進(jìn)續(xù)傳狀態(tài)而不是從頭再來(lái)。2.3 并發(fā)數(shù)和分片大小的選擇邏輯分片大小和并發(fā)數(shù)是整個(gè)方案里最需要權(quán)衡的兩個(gè)參數(shù)。切得太小分片數(shù)量暴增請(qǐng)求次數(shù)多了后端壓力大而且每個(gè)請(qǐng)求都有TCP握手和HTTP頭開(kāi)銷(xiāo)總耗時(shí)反而變長(zhǎng)。切得太大單個(gè)請(qǐng)求又回到了大請(qǐng)求容易斷的老問(wèn)題。我在這套系統(tǒng)里用的是5MB一片并發(fā)3個(gè)請(qǐng)求。算一下3.5GB 3584MB正好切714片默認(rèn)帶寬下并發(fā)3路每片獨(dú)立確認(rèn)整體進(jìn)度只增不減。并發(fā)數(shù)為什么是3而不是10因?yàn)闉g覽器對(duì)同一域名的TCP連接默認(rèn)限制是6個(gè)如果前端還有其他接口要調(diào)用占滿連接池會(huì)導(dǎo)致頁(yè)面其他請(qǐng)求排隊(duì)等待。留3個(gè)連接給普通接口調(diào)用上傳占3個(gè)是綜合體驗(yàn)最穩(wěn)的配比。3. 前端源碼實(shí)現(xiàn)切片、并發(fā)池、進(jìn)度與重試前端這部分我直接貼核心代碼基于原生JavaScript實(shí)現(xiàn)不依賴(lài)框架你把它接進(jìn)Vue、React或者單純的jQuery頁(yè)面都能用。先說(shuō)明一下整體結(jié)構(gòu)File切片用File.slice()MD5計(jì)算用SparkedMD5庫(kù)并發(fā)控制自己寫(xiě)一個(gè)簡(jiǎn)單的請(qǐng)求池不用第三方庫(kù)方便理解也方便改。3.1 文件的讀取與分片切片本身特別簡(jiǎn)單但要注意分片序號(hào)必須補(bǔ)零。后面合并時(shí)要按字典序排序如果不補(bǔ)零10會(huì)排在2前面文件順序就亂了。const CHUNK_SIZE 5 * 1024 * 1024; // 5MB function createChunks(file) { const count Math.ceil(file.size / CHUNK_SIZE); const chunks []; for (let i 0; i count; i) { const start i * CHUNK_SIZE; const end Math.min(start CHUNK_SIZE, file.size); chunks.push({ index: i, indexStr: String(i).padStart(6, 0), // 補(bǔ)零保證排序正確 blob: file.slice(start, end) }); } return chunks; }padStart(6, 0)這行是關(guān)鍵別省。700多片最多三位數(shù)補(bǔ)6位是為了以后超大文件擴(kuò)展時(shí)不用改代碼。切完以后每個(gè)分片就是一個(gè)獨(dú)立的小Blob對(duì)象5MB的小塊發(fā)給后端資源占用完全可控。3.2 MD5指紋計(jì)算用Web Worker避免卡死頁(yè)面計(jì)算3.5GB文件的MD5不是瞬間的事在純前端主線程里算會(huì)導(dǎo)致頁(yè)面卡頓用戶(hù)以為瀏覽器死了。解決方案是把計(jì)算丟到Web Worker里。我用的是SparkMD5的增量計(jì)算模式逐片讀取文件邊讀邊算不把整個(gè)文件加載進(jìn)內(nèi)存。// worker.js importScripts(spark-md5.min.js); self.onmessage function(e) { const file e.data.file; const chunkSize e.data.chunkSize; const spark new SparkMD5.ArrayBuffer(); let offset 0; const total file.size; function readNext() { if (offset total) { const hex spark.end(); self.postMessage({ type: done, hex }); return; } const blob file.slice(offset, Math.min(offset chunkSize, total)); const reader new FileReader(); reader.onload function(event) { spark.append(event.target.result); offset event.target.result.byteLength; // 每算完一塊匯報(bào)一次進(jìn)度 self.postMessage({ type: progress, percent: Math.round(offset / total * 100) }); readNext(); }; reader.readAsArrayBuffer(blob); } readNext(); };主線程那邊只需要function calcFileMD5(file) { return new Promise((resolve, reject) { const worker new Worker(worker.js); worker.postMessage({ file, chunkSize: CHUNK_SIZE }); worker.onmessage (e) { if (e.data.type progress) { updateHashProgress(e.data.percent); // 展示正在校驗(yàn)文件提示條 } else if (e.data.type done) { worker.terminate(); resolve(e.data.hex); } }; worker.onerror reject; }); }3GB的文件用這種方式算MD5大概需要20到40秒取決于CPU性能。體驗(yàn)上要給用戶(hù)明確反饋不然用戶(hù)以為卡死了直接把頁(yè)面關(guān)了。3.3 請(qǐng)求并發(fā)池的實(shí)現(xiàn)并發(fā)池是前端控制上傳節(jié)奏的核心。它的作用是同時(shí)最多跑3個(gè)上傳請(qǐng)求一個(gè)完成了馬上從待上傳隊(duì)列里拿下一個(gè)補(bǔ)上。這樣不會(huì)把瀏覽器連接池占滿也能保證進(jìn)度條平滑前移。async function uploadChunks(chunks, fileId, onProgress) { const concurrency 3; const queue [...chunks]; const results new Array(chunks.length); let completed 0; async function worker() { while (queue.length 0) { const chunk queue.shift(); const formData new FormData(); formData.append(fileId, fileId); formData.append(chunkIndex, chunk.indexStr); formData.append(chunk, chunk.blob); try { await axios.post(/api/upload/chunk, formData, { timeout: 120000, // 單分片超時(shí)2分鐘 onUploadProgress: () {} }); results[chunk.index] true; completed; onProgress(Math.round(completed / chunks.length * 100)); } catch (err) { // 單片失敗重試3次仍然失敗就中斷并拋出 await retryUpload(chunk, fileId, 3); completed; onProgress(Math.round(completed / chunks.length * 100)); } } } const workers []; for (let i 0; i concurrency; i) { workers.push(worker()); } await Promise.all(workers); return results; }這里注意一個(gè)細(xì)節(jié)單分片超時(shí)設(shè)置成了2分鐘。5MB的分片哪怕是撥號(hào)網(wǎng)絡(luò)也不該傳2分鐘設(shè)置這個(gè)值的意義是防止某個(gè)請(qǐng)求卡死導(dǎo)致并發(fā)池里的worker永遠(yuǎn)不釋放拖慢整個(gè)隊(duì)列。超時(shí)后主動(dòng)失敗觸發(fā)重試邏輯新的請(qǐng)求會(huì)重新加入排隊(duì)。3.4 進(jìn)度的精確計(jì)算進(jìn)度條不應(yīng)該是某一片正在傳就顯示那一小段的百分比而是以已成功落盤(pán)的分片數(shù)量為準(zhǔn)。每成功一片進(jìn)度 成功片數(shù) / 總分片數(shù)。這種計(jì)算方式不受單片傳輸速度波動(dòng)影響用戶(hù)看到的進(jìn)度條是穩(wěn)定向前的。有兩點(diǎn)要特別提示前端開(kāi)發(fā)注意一是進(jìn)度到達(dá)100%不代表上傳完成后端還要合并需要把狀態(tài)切成服務(wù)器合并中二是進(jìn)度條卡在99%一定不要慌張那是因?yàn)楹喜㈦A段沒(méi)有獨(dú)立的進(jìn)度反饋等后端合并完成就好了。如果你想讓體驗(yàn)更好可以在合并接口被調(diào)用后輪詢(xún)一個(gè)合并狀態(tài)接口展示真實(shí)的合并進(jìn)度后面我會(huì)講到后端如何配合。4. 后端源碼實(shí)現(xiàn)分片接收、索引校驗(yàn)與安全合并后端我用Node.js Express來(lái)寫(xiě)因?yàn)檫@在一線環(huán)境里最容易快速部署和二次開(kāi)發(fā)。如果你所在的企業(yè)后端是Java或.NET邏輯完全一致只需要把文件操作、接口返回?fù)Q成對(duì)應(yīng)的方言即可。目錄結(jié)構(gòu)我先給出來(lái)upload-service/ ├── app.js ├── config.js ├── uploads/ │ ├── tmp/ # 分片臨時(shí)目錄 │ └── files/ # 合并后的正式文件 └── routes/ ├── init.js ├── chunk.js ├── query.js └── merge.js4.1 初始化接口拿到文件唯一憑證前端算完MD5后調(diào)用這個(gè)接口后端返回fileId這個(gè)ID貫穿整個(gè)上傳生命周期。// routes/init.js const crypto require(crypto); const fs require(fs); const path require(path); const { tmpDir } require(../config); router.post(/init, async (req, res) { const { fileName, fileSize, chunkCount, md5 } req.body; // 1. 秒傳檢查MD5已存在則直接返回已完成 const exists await findFileByMd5(md5); if (exists) { return res.json({ code: 0, data: { fileId: exists.fileId, uploaded: true, message: 文件已存在秒傳成功 } }); } // 2. 斷點(diǎn)續(xù)傳檢查如果有未完成的上傳記錄則復(fù)用 const existing await findUploadRecord(md5); if (existing) { return res.json({ code: 0, data: { fileId: existing.fileId, uploaded: false } }); } // 3. 新建上傳記錄 const fileId crypto.randomUUID().replace(/-/g, ); const task { fileId, fileName, fileSize, chunkCount, md5, status: uploading, uploadedChunks: [], createTime: Date.now() }; // 落庫(kù)同時(shí)創(chuàng)建臨時(shí)目錄 await saveUploadRecord(task); fs.mkdirSync(path.join(tmpDir, fileId), { recursive: true }); res.json({ code: 0, data: { fileId, uploaded: false } }); });秒傳這個(gè)分支一定要做在初始化階段而不是合并階段這樣能省掉整個(gè)上傳過(guò)程的帶寬和計(jì)算資源。4.2 分片寫(xiě)入接口與完整性校驗(yàn)分片接口接收的是multipart/form-data格式前端每次提交一片后端把這片追加寫(xiě)入臨時(shí)目錄。這里我做兩個(gè)校驗(yàn)分片序號(hào)必須落在合法范圍內(nèi)分片大小不能超過(guò)約定上限防止惡意請(qǐng)求寫(xiě)壞磁盤(pán)。// routes/chunk.js const multer require(multer); const fs require(fs); const path require(path); router.post(/chunk, multer().single(chunk), async (req, res) { const { fileId, chunkIndex } req.body; const chunkIndexNum parseInt(chunkIndex, 10); const record await findUploadRecord(fileId); if (!record) { return res.status(404).json({ code: 404, message: 上傳記錄不存在 }); } if (chunkIndexNum 0 || chunkIndexNum record.chunkCount) { return res.status(400).json({ code: 400, message: 非法分片序號(hào) }); } if (req.file.size 5 * 1024 * 1024 1024) { return res.status(400).json({ code: 400, message: 分片大小超限 }); } const chunkPath path.join(tmpDir, fileId, ${chunkIndex}.part); fs.writeFileSync(chunkPath, req.file.buffer); await markChunkUploaded(fileId, chunkIndexNum); res.json({ code: 0, message: 分片寫(xiě)入成功 }); });分片文件名用純數(shù)字加.part后綴方便合并時(shí)排序。這里為了方便直接用了writeFileSync因?yàn)閱蝹€(gè)分片只有5MB內(nèi)存壓力不大。如果你把分片調(diào)到20MB以上建議改成流式寫(xiě)入避免多并發(fā)時(shí)內(nèi)存暴漲。這里還涉及一個(gè)容易被忽略的點(diǎn)服務(wù)端必須記錄已上傳分片否則斷點(diǎn)續(xù)傳無(wú)從談起。我在markChunkUploaded里做的是更新數(shù)據(jù)庫(kù)記錄把分片序號(hào)追加到一個(gè)數(shù)組字段里。更穩(wěn)妥的方案是一個(gè)分片一條記錄用獨(dú)立的表存儲(chǔ)這樣查詢(xún)已上傳分片時(shí)可以直接用索引。4.3 合并接口流式合并而不是內(nèi)存拼接合并是整個(gè)后端最容易翻車(chē)的地方。新手最容易犯的錯(cuò)誤是用Buffer.concat()把所有分片拼起來(lái)再寫(xiě)文件幾個(gè)GB的文件直接內(nèi)存溢出。正確做法是用Node.js的createReadStream和createWriteStream流水線式合并每次只讀寫(xiě)一小塊。// routes/merge.js const fs require(fs); const path require(path); const { Transform } require(stream); router.post(/merge, async (req, res) { const { fileId } req.body; const record await findUploadRecord(fileId); const uploadedCount record.uploadedChunks.length; if (uploadedCount ! record.chunkCount) { return res.status(400).json({ code: 400, message: 尚有分片未上傳還需${record.chunkCount - uploadedCount}片 }); } const destPath path.join(filesDir, record.fileName); const writeStream fs.createWriteStream(destPath); // 按分片序號(hào)排序 const sortedChunks Array.from({ length: record.chunkCount }, (_, i) i); async function appendChunk(index) { if (index sortedChunks.length) { writeStream.end(); return; } const chunkPath path.join(tmpDir, fileId, ${sortedChunks[index]}.part); const readStream fs.createReadStream(chunkPath); readStream.on(end, () appendChunk(index 1)); readStream.on(error, (err) { writeStream.destroy(); res.status(500).json({ code: 500, message: 合并失敗分片${index}讀取出錯(cuò) }); }); readStream.pipe(writeStream, { end: false }); } appendChunk(0); });合并這種寫(xiě)法本質(zhì)上就是挨個(gè)把分片文件接起來(lái)像拼水管一樣。這里每個(gè)分片的讀取是流式的內(nèi)存占用始終只有幾百KB不會(huì)因?yàn)槲募蠖鲩L(zhǎng)。合并完成之后還要做一次完整的校驗(yàn)計(jì)算合并后文件的MD5與初始化時(shí)的MD5比對(duì)。一致才更新上傳狀態(tài)為完成。這一步不能省網(wǎng)絡(luò)傳輸環(huán)節(jié)雖然每個(gè)分片的TCP校驗(yàn)都過(guò)了一遍但拼接順序、分片內(nèi)容丟失這類(lèi)邏輯錯(cuò)誤只有整體MD5才能抓出來(lái)。4.4 臨時(shí)分片的生命周期管理合并完成后臨時(shí)分片目錄要及時(shí)清理。我是用一個(gè)定時(shí)任務(wù)每小時(shí)掃描一次臨時(shí)目錄清理兩類(lèi)文件合并完成后遺留的分片以及超過(guò)24小時(shí)沒(méi)有新分片的半截上傳記錄。這里有個(gè)業(yè)務(wù)考量保留24小時(shí)是為了給斷點(diǎn)續(xù)傳留余地用戶(hù)今天傳了一半下班了明天還能續(xù)傳。超過(guò)24小時(shí)基本可以判定是放棄上傳了僵尸分片會(huì)占據(jù)硬盤(pán)空間必須清掉。清理時(shí)還要同步清理數(shù)據(jù)庫(kù)里的上傳記錄避免記錄越積越多拖慢查詢(xún)。5. 讓3.5GB真正傳完的可靠性設(shè)計(jì)代碼能跑通是一回事真正讓幾個(gè)GB的文件在各種惡劣網(wǎng)絡(luò)環(huán)境下都能傳完是另一回事。我在這里把上線過(guò)程中驗(yàn)證過(guò)的可靠性機(jī)制完整列出來(lái)。這些機(jī)制單獨(dú)看都是小改動(dòng)合在一起才是3.5GB一次傳完的底氣。5.1 網(wǎng)絡(luò)層超時(shí)、重試與并發(fā)降級(jí)分片上傳最大的好處是單次請(qǐng)求變小了但小請(qǐng)求同樣會(huì)遇到超時(shí)和斷連。我的處理策略是三層兜底單分片請(qǐng)求超時(shí)120秒超時(shí)就中斷中斷后的分片自動(dòng)重試最多3次每次間隔指數(shù)退避2秒、4秒、8秒連續(xù)3次失敗后并發(fā)數(shù)從3降為1用單線程繼續(xù)傳這樣能避免在網(wǎng)絡(luò)質(zhì)量極差時(shí)多個(gè)并發(fā)請(qǐng)求互相爭(zhēng)搶帶寬反而一個(gè)都傳不完。這層邏輯寫(xiě)在前端并發(fā)池的worker里后端不需要感知。后端要做的反而是把超時(shí)時(shí)間設(shè)得盡量寬松一些避免因?yàn)榫W(wǎng)關(guān)代理的默認(rèn)超時(shí)把慢速請(qǐng)求提前掐斷。如果你們Nginx配了proxy_read_timeout建議調(diào)到180秒以上。5.2 服務(wù)端崩潰后如何續(xù)傳服務(wù)端重啟、磁盤(pán)滿、進(jìn)程被殺這些故障都會(huì)中斷上傳過(guò)程。但只要分片已經(jīng)落盤(pán)、上傳記錄寫(xiě)進(jìn)了數(shù)據(jù)庫(kù)前端感知到連接斷開(kāi)后重新走一遍初始化流程后端發(fā)現(xiàn)同名MD5的上傳記錄還在返回同一個(gè)fileId前端再查詢(xún)已上傳分片就能精準(zhǔn)定位到中斷位置。這套機(jī)制的關(guān)鍵在于每個(gè)分片寫(xiě)入必須是原子操作。也就是要么完全寫(xiě)成功要么完全不寫(xiě)。writeFileSync天然具備這個(gè)特性只要不出現(xiàn)寫(xiě)一半進(jìn)程被殺的情況。為了更穩(wěn)我建議分片文件名里包含分片序號(hào)寫(xiě)入時(shí)先寫(xiě)臨時(shí)名再rename成正式名rename是原子操作更安全。5.3 頁(yè)面層關(guān)閉標(biāo)簽頁(yè)后的恢復(fù)方案用戶(hù)傳了一半關(guān)了標(biāo)簽頁(yè)再回來(lái)發(fā)現(xiàn)進(jìn)度條歸零會(huì)非常崩潰。前端要做的是把上傳狀態(tài)持久化到localStorage包含fileId、文件名、文件大小、MD5、總分片數(shù)。用戶(hù)重新選擇同一個(gè)文件時(shí)先查localStorage發(fā)現(xiàn)相同大小的文件且MD5一致直接調(diào)用后端查詢(xún)接口恢復(fù)進(jìn)度條。function saveUploadTask(file, fileId, md5) { localStorage.setItem(uploadTask, JSON.stringify({ fileName: file.name, fileSize: file.size, fileId, md5, uploadTime: Date.now() })); } async function resumeUploadIfNeeded(file) { const saved localStorage.getItem(uploadTask); if (!saved) return null; const task JSON.parse(saved); if (task.fileName ! file.name || task.fileSize ! file.size) return null; const { data } await axios.post(/api/upload/query, { fileId: task.fileId }); // data.uploadedChunks: 已上傳分片序號(hào)數(shù)組 return { task, uploadedChunks: data.uploadedChunks }; }注意localStorage有5MB大小限制這里只保存描述信息不保存文件本身不會(huì)越界。5.4 磁盤(pán)與存儲(chǔ)合并前的最后一公里后端存儲(chǔ)是整個(gè)鏈路里最容易靜默崩潰的一環(huán)。分片寫(xiě)入階段臨時(shí)目錄可能迅速膨脹幾個(gè)大文件同時(shí)在傳時(shí)磁盤(pán)占用是幾倍于最終文件大小的。我遇到過(guò)生產(chǎn)環(huán)境磁盤(pán)滿導(dǎo)致分片寫(xiě)不進(jìn)去前端一直報(bào)網(wǎng)絡(luò)錯(cuò)誤排查半天才發(fā)現(xiàn)是磁盤(pán)問(wèn)題。建議從第一天起就加三樣?xùn)|西磁盤(pán)剩余空間監(jiān)控低于10%告警、臨時(shí)目錄的獨(dú)立掛載盤(pán)與系統(tǒng)盤(pán)分離避免寫(xiě)滿系統(tǒng)盤(pán)、以及合并完成后的文件歸檔策略正式文件立即轉(zhuǎn)存到獨(dú)立存儲(chǔ)或?qū)ο蟠鎯?chǔ)應(yīng)用服務(wù)器只保留最近幾天的文件。6. 上線后踩過(guò)的坑從413到文件損壞的完整排查鏈路方案上線兩周問(wèn)題一個(gè)接一個(gè)冒出來(lái)。很多坑在開(kāi)發(fā)環(huán)境根本測(cè)不出來(lái)只有真正跑到供應(yīng)商的真實(shí)網(wǎng)絡(luò)和生產(chǎn)環(huán)境里才暴露。我把這幾個(gè)坑按排查鏈路寫(xiě)出來(lái)你照著這個(gè)順序排查能省大量時(shí)間。6.1 第一個(gè)坑Nginx默認(rèn)限制導(dǎo)致的413上線當(dāng)天就有供應(yīng)商反饋小文件能傳大文件一點(diǎn)上傳就報(bào)413 Request Entity Too Large。我第一時(shí)間想到的不是應(yīng)用代碼而是Nginx的client_max_body_size默認(rèn)值是1MB。分片雖然是5MB但這個(gè)限制作用于整個(gè)請(qǐng)求體大小所以5MB的分片請(qǐng)求也會(huì)被Nginx擋下來(lái)。排查鏈路很簡(jiǎn)單先看瀏覽器開(kāi)發(fā)者工具里的網(wǎng)絡(luò)請(qǐng)求發(fā)現(xiàn)POST /api/upload/chunk返回413再確認(rèn)請(qǐng)求體確實(shí)約5MB最后登錄服務(wù)器檢查Nginx配置。修復(fù)也直接server { client_max_body_size 10m; client_body_buffer_size 128k; proxy_request_buffering off; }為什么加proxy_request_buffering off因?yàn)槟J(rèn)開(kāi)啟時(shí)Nginx會(huì)把完整請(qǐng)求體緩沖到磁盤(pán)再轉(zhuǎn)發(fā)給后端分片這種流式提交場(chǎng)景等緩沖完再轉(zhuǎn)發(fā)會(huì)帶來(lái)無(wú)謂的延遲和磁盤(pán)IO。關(guān)閉后直接流式轉(zhuǎn)發(fā)給Node進(jìn)程。注意這里10m上限要大于分片大小的實(shí)際值留出multipart格式的額外開(kāi)銷(xiāo)余量。6.2 第二個(gè)坑負(fù)載均衡把分片拆到了兩臺(tái)機(jī)器這個(gè)是排查時(shí)間最長(zhǎng)的坑。供應(yīng)商反饋文件傳到一半報(bào)錯(cuò)查看后端日志發(fā)現(xiàn)有的分片寫(xiě)入成功有的直接404。仔細(xì)檢查后發(fā)現(xiàn)問(wèn)題出在部署架構(gòu)上服務(wù)跑在負(fù)載均衡后面的兩臺(tái)機(jī)器上同一個(gè)上傳任務(wù)的分片A請(qǐng)求被負(fù)載均衡轉(zhuǎn)發(fā)到節(jié)點(diǎn)1分片B請(qǐng)求被轉(zhuǎn)發(fā)到節(jié)點(diǎn)2兩臺(tái)機(jī)器各自的磁盤(pán)上只有一半分片合并接口在所有節(jié)點(diǎn)上都找不到完整數(shù)據(jù)。解決方案有兩種我選了比較簡(jiǎn)單的那種做應(yīng)用層會(huì)話保持。在負(fù)載均衡配置里按fileId做哈希路由保證同一個(gè)fileId的所有分片請(qǐng)求都落到同一個(gè)節(jié)點(diǎn)。更徹底的方案是把臨時(shí)目錄掛到共享存儲(chǔ)上但那個(gè)改動(dòng)太大不是緊急情況不值得動(dòng)。如果你用的是阿里云SLB或Nginx upstream有個(gè)更穩(wěn)妥的處理方式分片接口不依賴(lài)會(huì)話保持而是把分片數(shù)據(jù)直接寫(xiě)到共享的存儲(chǔ)層比如NFS或?qū)ο蟠鎯?chǔ)各節(jié)點(diǎn)讀取同一份數(shù)據(jù)。這屬于一次性投入以后擴(kuò)容也方便。6.3 第三個(gè)坑分片排序的字典序陷阱這個(gè)坑特別隱蔽而且只在文件超過(guò)100片時(shí)出現(xiàn)。某供應(yīng)商傳一個(gè)600MB的壓縮包合并后文件損壞解壓報(bào)錯(cuò)。我一開(kāi)始以為是分片丟失數(shù)了一遍數(shù)量是齊的又懷疑是某個(gè)分片內(nèi)容損壞但MD5對(duì)不上。最后把合并后的文件按順序?qū)Ρ仍嘉募l(fā)現(xiàn)有些數(shù)據(jù)塊順序反了。原因就是我在前端只用了String(i)做序號(hào)沒(méi)補(bǔ)零后端合并時(shí)用字符串排序10排到了2前面。雖然前端createChunks里已經(jīng)修正了這個(gè)問(wèn)題但當(dāng)時(shí)后端合并邏輯里自己也重新組裝了一次分片列表用的還是普通數(shù)組順序沒(méi)按補(bǔ)零后的字符串排。教訓(xùn)有兩條一是前端序號(hào)的padStart(6,0)必須做二是后端在合并前要把分片序號(hào)轉(zhuǎn)成數(shù)字再排序不要用字符串。兩邊都按數(shù)字排序這個(gè)坑就徹底解決了。6.4 第四個(gè)坑合并進(jìn)度為零的假卡死進(jìn)度條走到100%接口遲遲不返回用戶(hù)端看到的是上傳完成但處理中一直轉(zhuǎn)圈。排查后發(fā)現(xiàn)是合并時(shí)沒(méi)有給前端進(jìn)度反饋大文件合并要幾十秒用戶(hù)沒(méi)有任何提示體驗(yàn)上就是卡死了。我的解決辦法是把合并改成長(zhǎng)輪詢(xún)后端合并時(shí)把進(jìn)度寫(xiě)進(jìn)Redis前端啟動(dòng)合并后每2秒拉一次合并狀態(tài)接口展示單獨(dú)的合并進(jìn)度條。合并完成后前端彈出結(jié)果提示同時(shí)把localStorage里的上傳任務(wù)清掉。順帶還發(fā)現(xiàn)一個(gè)細(xì)節(jié)合并狀態(tài)接口要設(shè)置合理的緩存頭否則前端每次拉取都會(huì)走完整HTTP鏈路浪費(fèi)資源。我用的是Cache-Control: no-store因?yàn)闋顟B(tài)是實(shí)時(shí)變化的絕不能緩存。最后一點(diǎn)個(gè)人體會(huì)整套方案從設(shè)計(jì)到上線用了一個(gè)多月跑通核心流程只用了一周剩余時(shí)間幾乎都花在踩坑和加固上。如果讓我給正準(zhǔn)備做大附件上傳的人一個(gè)建議那就是不要沉迷于一次性把代碼寫(xiě)完美先把主流程跑通然后把網(wǎng)絡(luò)故障當(dāng)成必然事件來(lái)設(shè)計(jì)。大附件上傳的本質(zhì)不是上傳而是對(duì)抗不確定性——網(wǎng)絡(luò)會(huì)斷、服務(wù)器會(huì)重啟、用戶(hù)會(huì)中途關(guān)瀏覽器、磁盤(pán)會(huì)滿、代理會(huì)超時(shí)。把這些場(chǎng)景先想清楚代碼怎么寫(xiě)都對(duì)。另外有一件小事值得提汽車(chē)行業(yè)對(duì)文件的合規(guī)要求比一般行業(yè)嚴(yán)涉及供應(yīng)商提交的文件我們后來(lái)給每個(gè)分片加了上傳人的身份信息記錄合并完成后生成完整的審計(jì)日志。雖然這跟分片上傳本身關(guān)系不大但如果你做的系統(tǒng)要過(guò)體系審核最好提前把這條鏈路設(shè)計(jì)進(jìn)去別等審核組來(lái)查的時(shí)候再補(bǔ)那時(shí)候數(shù)據(jù)早就不全了。這套方案的源碼我手上還留著完整版包括前端組件化封裝、后端分片清理腳本的定時(shí)任務(wù)實(shí)現(xiàn)以及合并進(jìn)度的輪詢(xún)邏輯。篇幅原因沒(méi)法全部貼出來(lái)如果你在實(shí)際落地時(shí)遇到具體問(wèn)題歡迎在評(píng)論區(qū)帶上你的報(bào)錯(cuò)信息和技術(shù)棧我可以針對(duì)性地給出解釋。