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