傳方案解析)
1. 從一個幾十GB的BIM模型說起這個需求到底在解決什么1.1 場景還原國企工程建筑里的建模、審查與交付流程在建筑行業(yè)摸爬滾打過的朋友應該都有體會央企國企的工程項目和普通商業(yè)項目有本質區(qū)別體量大、周期長、參與方多而且對交付物有非常嚴格的歸檔要求。一個典型的大型公建項目結構、建筑、機電、幕墻、景觀各專業(yè)都要出模型這些模型經(jīng)過深化設計、碰撞檢查、施工模擬之后往往還要整合成一套“綜合模型”用于審查和交底。我之前參與過一個國企項目的平臺化改造當時碰到一個特別實際的問題各分包單位提交的BIM模型打包之后普遍在10GB到50GB之間單文件解包后更是動輒上百GB的零散文件。模型本身是按一定目錄結構組織的比如按樓棟號、按專業(yè)、按樓層、按構件庫分包目錄層級復雜文件名也帶著版本信息。這些模型要上傳到統(tǒng)一的Web管理平臺用于后續(xù)的進度對比、施工模擬和檔案留存。但問題來了普通的上傳方式根本扛不住。傳統(tǒng)的FormData整體提交瀏覽器端要讀整個文件到內存再把二進制數(shù)據(jù)拼進請求體幾GB的文件大概率直接把瀏覽器干崩潰或者卡在進度條上幾個小時不動。再加上國企內網(wǎng)環(huán)境的網(wǎng)絡波動、文件大小限制、服務器超時設置一次失敗就意味著從頭再來非常痛苦。這個項目標題里提到的“目錄結構分片斷點續(xù)傳”其實就是在解決這個場景下的三大痛點大文件如何穩(wěn)定上傳、上傳中斷后如何恢復、以及上傳后如何保持模型原有的目錄結構不亂。1.2 普通上傳為什么扛不住內存、超時和重傳的三重困境先說到底為什么傳統(tǒng)方案行不通。首先是瀏覽器內存問題。當我們用formData.append(file, file)這種方式上傳時如果直接傳入一個Blob對象瀏覽器本質上要把這個文件當做一個整體來處理。雖然現(xiàn)代瀏覽器在大部分情況下不會真的把整個文件一次性載入內存但部分老版本內核或資源受限的瀏覽器確實會這樣干內存直接被打滿。即便瀏覽器做了流式處理網(wǎng)絡層面的問題依然致命。內網(wǎng)環(huán)境下雖然帶寬理論上很高但國企內網(wǎng)往往有安全設備、審計網(wǎng)關、流量控制策略一條長連接很容易被中間設備超時掐斷。一個10GB的文件傳了8GB連接斷了服務器端接收到的臨時文件被清理掉前端只能重新開始。這個過程重復幾次現(xiàn)場工程師心態(tài)直接就崩了。整個文件上傳還有一個隱藏問題無法精確感知每一段的進度。HTML5的xhr.upload.onprogress確實能提供一個整體進度事件但那是基于當前請求的傳輸量計算的一旦請求被中斷這個進度就歸零。工程師看到的進度條從90%跳回0%這種體驗極其糟糕。所以分片上傳的思路本質上很簡單把一個大文件在瀏覽器端切成若干小塊逐塊上傳。每一塊都是獨立的HTTP請求服務端收到所有分片后再拼接成完整文件。這樣做的好處是某一片失敗只需要重傳這一片而不是整個文件而且每一片的狀態(tài)都可以被記錄刷新頁面、斷網(wǎng)、甚至瀏覽器崩潰之后只要知道哪些片傳成功了就可以從失敗的位置繼續(xù)傳。1.3 目標拆解分片、斷點續(xù)傳、目錄結構、校驗缺一不可在動手寫代碼之前我習慣先把這個標題拆成四個獨立的技術指標每一項都要在方案設計階段就想清楚第一個指標是“分片”。不管文件多大都要切割成可控大小的切片比如每片1MB到8MB前端逐片發(fā)送后端按順序拼接。第二個指標是“斷點續(xù)傳”。這是整個方案的靈魂。它要求前端能持久化記錄每一片的上傳狀態(tài)后端也能識別哪些分片已經(jīng)存在允許前端跳過已上傳的片直接從缺失位置繼續(xù)。第三個指標是“目錄結構”。這個在普通文件分片上傳方案里不太被提起但BIM模型場景特別重要。模型文件不是一個孤零零的二進制文件而是一個完整的目錄樹里面混著模型文件、貼圖資源、材質庫、鏈接文件、明細表等等。如果上傳后目錄樹被打平、層級丟失下游的所有工具都識別不出來。第四個指標是“完整性校驗”。分片上傳不等于丟數(shù)據(jù)每片上傳后要有哈希校驗合并完成后也要有整體校驗確保拼接出來的文件和本地文件完全一致。BIM模型一旦某個字節(jié)損壞輕則模型打不開重則算量結果錯誤這在工程領域是絕對不允許的。我的建議是先把這個需求搞清楚再想技術方案。很多人一上來就搜“分片上傳插件”往項目里裝了一個結果發(fā)現(xiàn)插件只能傳單個文件不保留目錄結構也沒有斷點記錄最后還是得自己改。與其繞彎子不如直接基于原生JavaScript和File API來實現(xiàn)所有邏輯都握在自己手里后續(xù)調試和擴展都方便。2. 技術方案設計先想清楚再寫代碼2.1 分片上傳的核心原理切片大小為什么通常選1MB到8MB分片上傳的第一件事就是確定切片大小。這個參數(shù)不是拍腦袋定的它直接影響上傳效率和重傳代價。切片太小比如256KB分片數(shù)量會非常夸張。一個10GB的文件要切4萬片每片一個HTTP請求光握手開銷就把帶寬吃掉了。切片太大比如64MB雖然請求數(shù)量少了但單片的傳輸時間變長一旦網(wǎng)絡抖動導致某一片失敗重傳64MB數(shù)據(jù)的代價又太大同時服務端接收時對內存緩沖區(qū)的壓力也大。我一般建議在1MB到8MB之間取一個平衡值。打個比方這就像搬家時選紙箱的大小紙箱太大裝滿后搬不動一旦路上散了損失慘重紙箱太小一趟一趟跑腿累死而且紙箱本身占地方。1MB到8MB這個區(qū)間既能保證單片傳輸在幾秒內完成又能控制總片數(shù)在一個可管理范圍內。用節(jié)省流量的邏輯來算更直觀假設網(wǎng)絡平均傳輸速度是5MB/s選1MB切片每片大約0.2秒傳完選8MB切片每片大約1.6秒傳完兩者在WAN場景下差別并不大但在LAN場景下更小的切片反而因為請求數(shù)量過多而拉低吞吐。所以我實際用下來5MB左右是一個比較舒服的閾值。如果走的是互聯(lián)網(wǎng)而非內網(wǎng)再降到2MB會更穩(wěn)。每片切完之后要給每個分片生成一個唯一的標識。比較通用的做法是相對路徑 _ 文件大小 _ 最后修改時間 _ 切片序號。這個標識組合能大概率避免同名文件沖突而且方便定位。## 3. 前端實操目錄讀取、文件切片與斷點記錄的完整實現(xiàn)3.1 從目錄選擇到文件樹構建讓瀏覽器“看到”BIM模型的目錄結構BIM模型一般以文件夾形式交付文件夾內部有清晰的層級。在Web端要保留這個層級首先得讓瀏覽器能遍歷目錄。HTML5里input typefile webkitdirectory可以做到這一點。const input document.createElement(input); input.type file; input.webkitdirectory true; input.addEventListener(change, (e) { const files Array.from(e.target.files); const tree {}; for (const file of files) { const relativePath file.webkitRelativePath; const segments relativePath.split(/); let current tree; for (let i 0; i segments.length - 1; i) { if (!current[segments[i]]) current[segments[i]] {}; current current[segments[i]]; } current[segments[segments.length - 1]] { size: file.size, lastModified: file.lastModified, type: file.type || }; } window.__fileTree tree; window.__files files; });需要注意的是webkitRelativePath在大多數(shù)Chromium內核瀏覽器中都能正常返回類似結構模型/B2號樓/結構.rvt這樣的相對路徑。拿到這個路徑之后我建議立刻生成一份JSON格式的目錄樹這份JSON有兩個用途一是上傳完成后給服務端做目錄重建依據(jù)二是前端自己展示文件列表時用。還有個容易被忽略的問題目錄里可能包含隱藏文件、臨時文件、回收站殘留之類的東西。在構建文件樹時最好做一層過濾比如排除以.開頭的文件、排除__MACOSX這類常見打包殘留目錄。國企項目移交過來的模型經(jīng)常帶著各種莫名其妙的文件傳上去之后不僅浪費流量后期清理還很麻煩。3.2 文件切片與標識生成File.slice和穩(wěn)定ID的配合文件切割在瀏覽器端非常簡單核心就是一個APIfunction createChunks(file, chunkSize 5 * 1024 * 1024) { const chunks []; let start 0; while (start file.size) { chunks.push(file.slice(start, start chunkSize)); start chunkSize; } return chunks; }file.slice()返回的是一個Blob對象它并不會真的把文件內容復制出來而是指向原始文件數(shù)據(jù)的某一段因此內存消耗相對可控。不過這里有一個必須注意的細節(jié)如果對文件調用slice之后原文件對象被釋放某些瀏覽器下這些Blob會變成無效引用。所以在上傳期間最好用一個數(shù)組把所有切片引用保存住直到全部上傳完成。對于斷點續(xù)傳每個分片需要有一個穩(wěn)定且唯一的標識。我建議把標識拆成兩個層級文件級別ID和分片級別索引。function buildFileId(file) { const path file.webkitRelativePath || file.name; return ${path}_${file.size}_${file.lastModified}; } function buildChunkId(fileId, index) { return ${fileId}_chunk_${index}; }這里我刻意沒有使用基于文件內容的哈希作為切片標識因為對大文件計算全量MD5或SHA-1在瀏覽器端是很慢的甚至可能造成主線程卡頓。用路徑 大小 最后修改時間來標識文件雖然理論上存在極小概率沖突但對內網(wǎng)交付的模型文件來說已經(jīng)足夠可靠。如果你需要更高強度的校驗可以只對第一個切片和最后一個切片做部分哈希這樣既能兼顧性能又能防止明顯的文件損壞。3.3 上傳隊列與并發(fā)控制別把服務器打懵分片數(shù)量上來之后一次性把所有分片同時發(fā)出去是不現(xiàn)實的。一個10GB的文件按5MB切大約2048片如果全部并發(fā)發(fā)起瀏覽器光在建TCP連接就把資源耗盡了而且服務端也沒辦法同時處理這么多請求。正確的做法是控制并發(fā)數(shù)。async function uploadChunksInParallel(chunks, fileId, concurrency 6) { let index 0; const tasks []; for (let i 0; i concurrency; i) { tasks.push(run()); } async function run() { while (index chunks.length) { const current index; const chunk chunks[current]; await uploadOneChunk(fileId, current, chunk); } } await Promise.all(tasks); }并發(fā)數(shù)取多少合適我試過比較多的方案內網(wǎng)環(huán)境下6到8路并發(fā)效果最佳外網(wǎng)環(huán)境下3到4路更快。這個數(shù)字取決于服務器配置、網(wǎng)關并發(fā)限制和網(wǎng)絡帶寬。如果并發(fā)設置太高網(wǎng)關可能會直接拒絕連接設置太低又無法利用多路并行加速。每一片的上傳請求需要包含三類信息文件標識、分片序號、分片二進制數(shù)據(jù)。服務端應該以文件標識 分片序號作為冪等鍵收到重復上傳時直接返回成功這樣前端在斷點續(xù)傳時反復嘗試同一片也不會出問題。3.4 IndexedDB記錄進度刷新之后繼續(xù)傳不靠運氣斷點續(xù)傳的核心在于“狀態(tài)記錄”。前端每次上傳完一片都應該把這一片的成功狀態(tài)記錄下來。刷新頁面或者瀏覽器崩潰之后通過查詢已經(jīng)上傳的分片列表就能跳過這些分片從失敗位置繼續(xù)傳。localStorage雖然簡單但容量有限通常5MB左右而且只能存字符串。一個10GB的文件有2048片每片記錄一個ID雖然字符串不會太大但如果同時管理多個文件可能就把localStorage撐爆了。更麻煩的是localStorage的讀寫是同步的頻繁寫入會阻塞UI線程。我建議用IndexedDB來存上傳進度。它容量大、異步、性能好非常適合做斷點恢復這種場景。先簡單封裝一個存儲工具const dbName bim-upload-db; const storeName chunk-status; function openDB() { return new Promise((resolve, reject) { const request indexedDB.open(dbName, 1); request.onupgradeneeded () { const db request.result; if (!db.objectStoreNames.contains(storeName)) { const store db.createObjectStore(storeName, { keyPath: chunkId }); store.createIndex(fileId, fileId, { unique: false }); } }; request.onsuccess () resolve(request.result); request.onerror () reject(request.error); }); } async function markChunkUploaded(fileId, chunkId) { const db await openDB(); return new Promise((resolve, reject) { const tx db.transaction(storeName, readwrite); tx.objectStore(storeName).put({ fileId, chunkId, uploaded: true }); tx.oncomplete resolve; tx.onerror () reject(tx.error); }); } async function getUploadedChunks(fileId) { const db await openDB(); return new Promise((resolve, reject) { const tx db.transaction(storeName, readonly); const store tx.objectStore(storeName); const index store.index(fileId); const request index.getAll(fileId); request.onsuccess () resolve(request.result.map(item item.chunkId)); request.onerror () reject(request.error); }); }有了這個進度存儲上傳流程就變成了啟動上傳前先查IndexedDB把已經(jīng)成功上傳的分片序號過濾掉只排尚未上傳的切片進入隊列。這樣一來哪怕之前傳了一半瀏覽器崩了下次打開頁面選擇同一目錄系統(tǒng)自動識別同一批文件ID直接跳過已傳部分。這里有個必須要提醒的點IndexedDB里的記錄是“前端視角”的它代表的只是瀏覽器曾經(jīng)發(fā)出過成功響應。如果服務端在接收某一片之后、返回成功之前崩潰了前端記錄成功但實際上后端的這一片是殘缺的。所以服務端必須在每次分片上傳時做文件大小的校驗拼接時再做一次整體校驗雙保險。3.5 合并請求與整體校驗分片傳完了不代表文件沒問題所有分片都傳完之后前端需要調用一個合并接口通知服務端把臨時目錄里的分片按順序拼接成完整文件。合并請求里要帶上文件ID、總大小、總分片數(shù)、原始相對路徑。服務端在做合并之前會先檢查分片數(shù)量和大小是否吻合再執(zhí)行合并。合并完成后我強烈建議做一次文件級校驗。最簡單的方式是前端在構建文件ID時記錄文件總大小合并后由服務端返回合并后的文件大小和哈希值前端進行比對。如果要做更嚴格的校驗可以對整個文件做一次MD5計算但大文件的整體哈希計算在服務端也需要一定時間所以實際工程中我更傾向于讓前端對文件的第一個和最后一個切片做MD5作為強校驗的近似替代其余切片用大小校驗兜底。校驗通過之后目錄樹JSON和文件實體是分離的。前端在上傳分片的同時應該把目錄樹數(shù)據(jù)一并提交給服務端元數(shù)據(jù)表。服務端拿到目錄樹和數(shù)據(jù)文件后會按相對路徑在目標存儲位置重建目錄結構把文件落到對應目錄節(jié)點下。這個過程可以在合并接口里一并處理省去一次請求。4. 后端配合接口設計、合并策略與存儲規(guī)劃4.1 三個核心接口初始化、上傳分片、合并前端做得再好后端接口設計跟不上也是白搭。我們只需要三個核心接口不復雜但每一步都要考慮邊界情況。第一個是初始化接口。前端在開始上傳前先調用它把自己要傳的文件ID、文件總大小、文件名、相對路徑發(fā)給服務端。服務端返回一個uploadId并在臨時目錄下創(chuàng)建以uploadId為名的子目錄后續(xù)該文件的所有分片都存在這個目錄里。第二個是上傳分片接口。請求參數(shù)包括uploadId、chunkIndex、chunkSize二進制分片數(shù)據(jù)放在請求體中。服務端把分片寫入臨時目錄/uploadId/chunkIndex.part然后返回成功。如果這個分片已經(jīng)存在且大小一致直接返回200不上傳也沒問題。第三個是合并接口。參數(shù)包括uploadId、文件總大小、總分片數(shù)、目錄樹JSON。服務端先校驗分片完整性然后按索引順序合并寫入最終存儲路徑最后重建目錄樹。合并成功之后刪除臨時目錄返回文件元數(shù)據(jù)。我遇到的比較常見的問題是很多團隊在初始化接口里就做了大量業(yè)務判斷比如數(shù)據(jù)庫查重、權限校驗、隊列檢查結果初始化慢得像龜速。工業(yè)級場景應該把初始化接口做得盡量輕量只負責創(chuàng)建上傳會話所有業(yè)務判斷放在后續(xù)流程里異步執(zhí)行。4.2 服務端分片存儲與合并策略流式拼接比內存拼接靠譜服務端接收分片時最容易犯的錯誤是把所有分片讀入內存再拼接。一個5MB的分片乘以2048片就是10GB內存正常的服務器根本扛不住。正確的做法是分部落地。每收到一片直接使用文件流寫入磁盤路徑按uploadId 序號組織。合并時逐片打開文件使用流式方式將內容追加到目標文件尾部。Node.js里用createReadStream和createWriteStream配合管道操作每合并完一片就關閉資源內存占用始終保持恒定。合并校驗的策略也要細化。我通常會維護一個分片元信息表記錄每片的實際大小。合并前檢查兩件事已上傳分片的數(shù)量是否等于總分片數(shù)、每片的大小是否與預期一致。如果發(fā)現(xiàn)缺失或缺損返回前端一個“缺失分片列表”讓前端針對性重傳缺失的片而不是整個文件重傳。這種“按需補片”機制在弱網(wǎng)環(huán)境下尤其好用。關于磁盤規(guī)劃臨時目錄要有獨立的分區(qū)不能和系統(tǒng)目錄混在一起。之前我遇到過一次項目臨時目錄寫在系統(tǒng)盤模型上傳量一大系統(tǒng)盤被塞滿整個服務器直接無響應。臨時目錄的清理策略也要有。合并成功之后立即刪除對應分片這是最基礎的要求。還要加一個定時任務清理超過48小時仍處于未完成狀態(tài)的上傳目錄防止黑客或異常任務占滿磁盤。4.3 并發(fā)沖突與重復分片的冪等處理上傳過程中前端可能會因為網(wǎng)絡超時對同一個分片重復請求。服務端必須對這種情況做冪等處理。用uploadId chunkIndex作為主鍵如果發(fā)現(xiàn)同一個分片已經(jīng)存在且大小一致就直接返回成功不重復寫磁盤。合并操作的并發(fā)控制同樣重要。我建議用一個鎖標記來防止同一個uploadId被多個合并請求同時操作。比如在數(shù)據(jù)庫會話表里加一個mergeStatus字段合并中、合并完成、合并失敗。前端偶爾會因為超時對合并接口重復請求一對服務端看到“合并中”狀態(tài)可以適當阻塞等待看到“合并完成”直接返回結果避免合并邏輯執(zhí)行兩次產(chǎn)生臟數(shù)據(jù)。5. 國企工程場景下繞不開的坑與排查實錄5.1 網(wǎng)絡波動與斷網(wǎng)恢復指數(shù)退避重試是基礎操作國企內網(wǎng)雖然有專線但不算穩(wěn)定。特別是部分老辦公樓里的網(wǎng)絡設備高峰期經(jīng)常出現(xiàn)大量丟包。分片上傳遇到單次網(wǎng)絡失敗是常態(tài)所以前端必須有一套重試機制。我比較推薦指數(shù)退避策略第一次失敗等1秒重試第二次失敗等2秒第三次等4秒最多重試5次。如果連續(xù)5次失敗就把這個分片標記為失敗但不中斷整個上傳流程而是繼續(xù)處理其他分片失敗的分片放到隊列末尾最后統(tǒng)一補傳。實際體驗下來這種“邊傳邊補”的策略比“遇到失敗就停止整個上傳”強太多因為網(wǎng)絡抖動通常是短暫的給一小段時間它自己就恢復了。斷網(wǎng)的情況更特殊。瀏覽器檢測到網(wǎng)絡斷開時所有請求會失敗。這時候前端應該暫停整個上傳隊列監(jiān)聽online事件網(wǎng)絡恢復后重新查詢IndexedDB里的上傳狀態(tài)對未完成的分片繼續(xù)上傳。在這個過程中不需要刷新頁面體驗是連續(xù)的。5.2 瀏覽器崩潰與內存占用優(yōu)化用Web Worker把哈希計算挪到后臺瀏覽器崩潰是分片上傳最容易遇到的問題大多數(shù)原因是內存占用過高。雖然File.slice()不會一次把整個文件載入內存但部分場景下比如多個文件同時讀取、切片對象持有大量引用內存還是會快速攀升。我的經(jīng)驗是每次從磁盤讀取一個切片后立即上傳并釋放引用不要一次性把所有切片都放進一個數(shù)組里。上面給出的createChunks示例雖然是全量創(chuàng)建但實際項目中我會改為懶加載切片function getChunk(file, chunkSize, index) { const start index * chunkSize; const end Math.min(start chunkSize, file.size); return file.slice(start, end); }這樣每次只保留當前正在上傳的幾片內存占用大幅降低。如果是做全量文件哈希校驗一定不要在主線程做。一個10GB文件的全量MD5計算在瀏覽器里可能需要幾十秒甚至幾分鐘在這期間頁面會卡死。正確做法是把文件交給Web Worker在Worker線程里分片讀取并計算哈希計算完畢通過postMessage把結果傳回主線程。這樣用戶可以繼續(xù)操作界面不會出現(xiàn)“頁面已失去響應”的尷尬。5.3 老舊瀏覽器與國產(chǎn)化內核兼容降級方案要提前想好國企辦公環(huán)境里瀏覽器的實際情況可能超出技術人員想象。有大量存量電腦還在使用老版本的Chromium內核瀏覽器有些國產(chǎn)瀏覽器默認跑在兼容模式下。這些環(huán)境下webkitdirectory、IndexedDB這些特性可能是缺失的。我建議在頁面加載時做一次能力檢測分別檢測File.slice、webkitdirectory、indexedDB是否可用。如果某一項缺失就啟用降級方案。比如沒有IndexedDB就用localStorage存進度沒有webkitdirectory就不支持目錄選擇改為讓用戶選擇單個文件或壓縮包實在不行就退回最原始的整包上傳方案。雖然這些降級方案體驗差很多但總比“打開頁面什么都做不了”強。我遇到過某國企內網(wǎng)瀏覽器連File.slice都不支持的情況那套系統(tǒng)所有文件上傳都只能走傳統(tǒng)方式這是平臺底層的硬傷前端只能盡量兼容沒法完全替代。### 5.4 安全與審計模型文件是核心資產(chǎn)不能裸奔BIM模型在工程項目里屬于核心數(shù)據(jù)資產(chǎn)里面包含了完整的建筑結構信息、設備參數(shù)、工程量清單一旦泄露或者被篡改后果非常嚴重。所以上傳過程不能只想著“傳上去就行”還得考慮安全與審計。權限控制是第一層。上傳接口必須驗證用戶身份不能匿名上傳。我當時所在的系統(tǒng)對接了統(tǒng)一的身份認證平臺上傳時每次請求都要攜帶token。分片上傳接口也同樣校驗不能因為它是“部分數(shù)據(jù)”就放寬權限。操作日志是第二層。上傳開始、分片接收、合并完成、文件刪除這些操作都要記錄到日志系統(tǒng)。日志里至少要包含操作人、操作時間、文件ID、分片序號、結果狀態(tài)。國企項目的審計是要落實到具體人和具體操作的這個不能省。文件校驗是第三層。合并完成后對文件做一次病毒掃描和類型檢測。你可能會覺得奇怪模型文件怎么會有病毒但實際上從外部協(xié)作單位移交的模型包經(jīng)?；烊敫鞣N可執(zhí)行文件、宏病毒、惡意鏈接。服務端在把文件暴露給其他系統(tǒng)訪問之前必須經(jīng)過安全檢測。這不僅是技術問題更是合規(guī)問題。6. 實測效果、踩坑記錄與可復用的經(jīng)驗6.1 實測環(huán)境與最終效果在項目收尾階段我們做了幾輪壓測。測試環(huán)境是一套典型的國企內網(wǎng)配置一臺4核8GB的應用服務器一臺文件存儲服務器客戶端是普通辦公電腦。測試對象是一個約35GB的綜合BIM模型包包含5600多個文件目錄層級在5層左右。使用5MB分片、6路并發(fā)、開啟IndexedDB斷點恢復的方案整體上傳耗時大約2小時左右。期間人為中斷了兩次網(wǎng)絡每次恢復后系統(tǒng)都能自動從斷點繼續(xù)沒有出現(xiàn)重復上傳已成功的分片。服務端合并完成后校驗文件大小與源文件完全一致目錄結構也按照原始樹狀關系落到了存儲區(qū)。相比之前用普通上傳方式“傳一天斷三次”的體驗這套方案可以說是從“不可用”變成了“可用”。6.2 踩過的坑與對應解決方法第一個坑是并發(fā)數(shù)設置過高導致服務端連接數(shù)被打滿。第一次測試時我圖快直接上了20路并發(fā)結果應用服務器的連接池瞬間被耗盡所有請求全部排隊等待整個Web應用的其他功能也跟著卡住。后來把并發(fā)數(shù)降到6問題消失。這個參數(shù)最好做成配置項根據(jù)實際服務器負載動態(tài)調整。第二個坑是目錄名里包含中文、空格和特殊符號。模型交付方經(jīng)常用“B2號樓-裝修-2024-最終版”這種命名方式。如果文件ID直接用整個相對路徑拼接偶爾會出現(xiàn)空格導致的解析錯誤。解決辦法是在生成文件ID時用編碼后的相對路徑或者把路徑單獨作為一個字段存放不在ID里直接拼接。第三個坑是合并時對大文件使用同步拼接導致服務端無響應。最初的實現(xiàn)是把所有分片讀入數(shù)組再用Buffer.concat合并一個4GB的文件直接導致內存溢出。改成流式合并之后就穩(wěn)定了。這就是我前面反復強調流式處理的原因——在這個場景里它不是一個可選項而是必須項。第四個坑是清理任務誤刪未完成的上傳目錄。定時清理我最初設置的閾值是24小時但有些超大模型文件因為網(wǎng)絡原因連續(xù)傳了超過24小時結果被清理任務在合并前刪掉了。后來我把閾值改成48小時并且加了個“有進行中上傳任務”的保護判斷才徹底解決。6.3 一個很實用的小技巧服務端返回缺失分片列表最后分享一個我自己覺得特別實用的技巧。在合并接口的校驗階段服務端除了返回“失敗”之外還要返回具體的缺失或異常分片序號列表。前端拿到這個列表后只需要重傳這幾片然后再次調用合并接口。這個過程可以循環(huán)直到合并成功。這種方法在處理“某些分片損壞但不清楚是哪些”的情況下非常高效比無腦全量重傳強一個量級。我之所以一直強調這個方案里的“分片斷點目錄結構”三件套要組合起來看是因為在真實的國企工程建筑場景里這三個需求從來都是同時出現(xiàn)的。一個只支持分片上傳、不支持斷點恢復的插件在弱網(wǎng)條件下仍然會讓工程師崩潰一個支持斷點但忽略目錄結構的上傳工具傳完之后下游工具用不了等于白傳。只有把三者打通才能真正解決生產(chǎn)環(huán)境里的問題。如果你也正在處理類似的需求建議先拿一個真實的BIM模型包做測試不要用幾個小文件模擬。真實場景下的大文件數(shù)量、目錄深度、命名習慣都會逼著你把邊界情況想清楚。這套方案跑通之后后續(xù)無論是擴展上傳進度展示、增加上傳任務隊列還是對接消息通知都是在現(xiàn)有骨架上做增量開發(fā)很順手。 BIM模型大文件分片上傳與斷點續(xù)傳方案解析
1. 從一個幾十GB的BIM模型說起這個需求到底在解決什么1.1 場景還原國企工程建筑里的建模、審查與交付流程在建筑行業(yè)摸爬滾打過的朋友應該都有體會央企國企的工程項目和普通商業(yè)項目有本質區(qū)別體量大、周期長、參與方多而且對交付物有非常嚴格的歸檔要求。一個典型的大型公建項目結構、建筑、機電、幕墻、景觀各專業(yè)都要出模型這些模型經(jīng)過深化設計、碰撞檢查、施工模擬之后往往還要整合成一套“綜合模型”用于審查和交底。我之前參與過一個國企項目的平臺化改造當時碰到一個特別實際的問題各分包單位提交的BIM模型打包之后普遍在10GB到50GB之間單文件解包后更是動輒上百GB的零散文件。模型本身是按一定目錄結構組織的比如按樓棟號、按專業(yè)、按樓層、按構件庫分包目錄層級復雜文件名也帶著版本信息。這些模型要上傳到統(tǒng)一的Web管理平臺用于后續(xù)的進度對比、施工模擬和檔案留存。但問題來了普通的上傳方式根本扛不住。傳統(tǒng)的FormData整體提交瀏覽器端要讀整個文件到內存再把二進制數(shù)據(jù)拼進請求體幾GB的文件大概率直接把瀏覽器干崩潰或者卡在進度條上幾個小時不動。再加上國企內網(wǎng)環(huán)境的網(wǎng)絡波動、文件大小限制、服務器超時設置一次失敗就意味著從頭再來非常痛苦。這個項目標題里提到的“目錄結構分片斷點續(xù)傳”其實就是在解決這個場景下的三大痛點大文件如何穩(wěn)定上傳、上傳中斷后如何恢復、以及上傳后如何保持模型原有的目錄結構不亂。1.2 普通上傳為什么扛不住內存、超時和重傳的三重困境先說到底為什么傳統(tǒng)方案行不通。首先是瀏覽器內存問題。當我們用formData.append(file, file)這種方式上傳時如果直接傳入一個Blob對象瀏覽器本質上要把這個文件當做一個整體來處理。雖然現(xiàn)代瀏覽器在大部分情況下不會真的把整個文件一次性載入內存但部分老版本內核或資源受限的瀏覽器確實會這樣干內存直接被打滿。即便瀏覽器做了流式處理網(wǎng)絡層面的問題依然致命。內網(wǎng)環(huán)境下雖然帶寬理論上很高但國企內網(wǎng)往往有安全設備、審計網(wǎng)關、流量控制策略一條長連接很容易被中間設備超時掐斷。一個10GB的文件傳了8GB連接斷了服務器端接收到的臨時文件被清理掉前端只能重新開始。這個過程重復幾次現(xiàn)場工程師心態(tài)直接就崩了。整個文件上傳還有一個隱藏問題無法精確感知每一段的進度。HTML5的xhr.upload.onprogress確實能提供一個整體進度事件但那是基于當前請求的傳輸量計算的一旦請求被中斷這個進度就歸零。工程師看到的進度條從90%跳回0%這種體驗極其糟糕。所以分片上傳的思路本質上很簡單把一個大文件在瀏覽器端切成若干小塊逐塊上傳。每一塊都是獨立的HTTP請求服務端收到所有分片后再拼接成完整文件。這樣做的好處是某一片失敗只需要重傳這一片而不是整個文件而且每一片的狀態(tài)都可以被記錄刷新頁面、斷網(wǎng)、甚至瀏覽器崩潰之后只要知道哪些片傳成功了就可以從失敗的位置繼續(xù)傳。1.3 目標拆解分片、斷點續(xù)傳、目錄結構、校驗缺一不可在動手寫代碼之前我習慣先把這個標題拆成四個獨立的技術指標每一項都要在方案設計階段就想清楚第一個指標是“分片”。不管文件多大都要切割成可控大小的切片比如每片1MB到8MB前端逐片發(fā)送后端按順序拼接。第二個指標是“斷點續(xù)傳”。這是整個方案的靈魂。它要求前端能持久化記錄每一片的上傳狀態(tài)后端也能識別哪些分片已經(jīng)存在允許前端跳過已上傳的片直接從缺失位置繼續(xù)。第三個指標是“目錄結構”。這個在普通文件分片上傳方案里不太被提起但BIM模型場景特別重要。模型文件不是一個孤零零的二進制文件而是一個完整的目錄樹里面混著模型文件、貼圖資源、材質庫、鏈接文件、明細表等等。如果上傳后目錄樹被打平、層級丟失下游的所有工具都識別不出來。第四個指標是“完整性校驗”。分片上傳不等于丟數(shù)據(jù)每片上傳后要有哈希校驗合并完成后也要有整體校驗確保拼接出來的文件和本地文件完全一致。BIM模型一旦某個字節(jié)損壞輕則模型打不開重則算量結果錯誤這在工程領域是絕對不允許的。我的建議是先把這個需求搞清楚再想技術方案。很多人一上來就搜“分片上傳插件”往項目里裝了一個結果發(fā)現(xiàn)插件只能傳單個文件不保留目錄結構也沒有斷點記錄最后還是得自己改。與其繞彎子不如直接基于原生JavaScript和File API來實現(xiàn)所有邏輯都握在自己手里后續(xù)調試和擴展都方便。2. 技術方案設計先想清楚再寫代碼2.1 分片上傳的核心原理切片大小為什么通常選1MB到8MB分片上傳的第一件事就是確定切片大小。這個參數(shù)不是拍腦袋定的它直接影響上傳效率和重傳代價。切片太小比如256KB分片數(shù)量會非常夸張。一個10GB的文件要切4萬片每片一個HTTP請求光握手開銷就把帶寬吃掉了。切片太大比如64MB雖然請求數(shù)量少了但單片的傳輸時間變長一旦網(wǎng)絡抖動導致某一片失敗重傳64MB數(shù)據(jù)的代價又太大同時服務端接收時對內存緩沖區(qū)的壓力也大。我一般建議在1MB到8MB之間取一個平衡值。打個比方這就像搬家時選紙箱的大小紙箱太大裝滿后搬不動一旦路上散了損失慘重紙箱太小一趟一趟跑腿累死而且紙箱本身占地方。1MB到8MB這個區(qū)間既能保證單片傳輸在幾秒內完成又能控制總片數(shù)在一個可管理范圍內。用節(jié)省流量的邏輯來算更直觀假設網(wǎng)絡平均傳輸速度是5MB/s選1MB切片每片大約0.2秒傳完選8MB切片每片大約1.6秒傳完兩者在WAN場景下差別并不大但在LAN場景下更小的切片反而因為請求數(shù)量過多而拉低吞吐。所以我實際用下來5MB左右是一個比較舒服的閾值。如果走的是互聯(lián)網(wǎng)而非內網(wǎng)再降到2MB會更穩(wěn)。每片切完之后要給每個分片生成一個唯一的標識。比較通用的做法是相對路徑 _ 文件大小 _ 最后修改時間 _ 切片序號。這個標識組合能大概率避免同名文件沖突而且方便定位。## 3. 前端實操目錄讀取、文件切片與斷點記錄的完整實現(xiàn)3.1 從目錄選擇到文件樹構建讓瀏覽器“看到”BIM模型的目錄結構BIM模型一般以文件夾形式交付文件夾內部有清晰的層級。在Web端要保留這個層級首先得讓瀏覽器能遍歷目錄。HTML5里input typefile webkitdirectory可以做到這一點。const input document.createElement(input); input.type file; input.webkitdirectory true; input.addEventListener(change, (e) { const files Array.from(e.target.files); const tree {}; for (const file of files) { const relativePath file.webkitRelativePath; const segments relativePath.split(/); let current tree; for (let i 0; i segments.length - 1; i) { if (!current[segments[i]]) current[segments[i]] {}; current current[segments[i]]; } current[segments[segments.length - 1]] { size: file.size, lastModified: file.lastModified, type: file.type || }; } window.__fileTree tree; window.__files files; });需要注意的是webkitRelativePath在大多數(shù)Chromium內核瀏覽器中都能正常返回類似結構模型/B2號樓/結構.rvt這樣的相對路徑。拿到這個路徑之后我建議立刻生成一份JSON格式的目錄樹這份JSON有兩個用途一是上傳完成后給服務端做目錄重建依據(jù)二是前端自己展示文件列表時用。還有個容易被忽略的問題目錄里可能包含隱藏文件、臨時文件、回收站殘留之類的東西。在構建文件樹時最好做一層過濾比如排除以.開頭的文件、排除__MACOSX這類常見打包殘留目錄。國企項目移交過來的模型經(jīng)常帶著各種莫名其妙的文件傳上去之后不僅浪費流量后期清理還很麻煩。3.2 文件切片與標識生成File.slice和穩(wěn)定ID的配合文件切割在瀏覽器端非常簡單核心就是一個APIfunction createChunks(file, chunkSize 5 * 1024 * 1024) { const chunks []; let start 0; while (start file.size) { chunks.push(file.slice(start, start chunkSize)); start chunkSize; } return chunks; }file.slice()返回的是一個Blob對象它并不會真的把文件內容復制出來而是指向原始文件數(shù)據(jù)的某一段因此內存消耗相對可控。不過這里有一個必須注意的細節(jié)如果對文件調用slice之后原文件對象被釋放某些瀏覽器下這些Blob會變成無效引用。所以在上傳期間最好用一個數(shù)組把所有切片引用保存住直到全部上傳完成。對于斷點續(xù)傳每個分片需要有一個穩(wěn)定且唯一的標識。我建議把標識拆成兩個層級文件級別ID和分片級別索引。function buildFileId(file) { const path file.webkitRelativePath || file.name; return ${path}_${file.size}_${file.lastModified}; } function buildChunkId(fileId, index) { return ${fileId}_chunk_${index}; }這里我刻意沒有使用基于文件內容的哈希作為切片標識因為對大文件計算全量MD5或SHA-1在瀏覽器端是很慢的甚至可能造成主線程卡頓。用路徑 大小 最后修改時間來標識文件雖然理論上存在極小概率沖突但對內網(wǎng)交付的模型文件來說已經(jīng)足夠可靠。如果你需要更高強度的校驗可以只對第一個切片和最后一個切片做部分哈希這樣既能兼顧性能又能防止明顯的文件損壞。3.3 上傳隊列與并發(fā)控制別把服務器打懵分片數(shù)量上來之后一次性把所有分片同時發(fā)出去是不現(xiàn)實的。一個10GB的文件按5MB切大約2048片如果全部并發(fā)發(fā)起瀏覽器光在建TCP連接就把資源耗盡了而且服務端也沒辦法同時處理這么多請求。正確的做法是控制并發(fā)數(shù)。async function uploadChunksInParallel(chunks, fileId, concurrency 6) { let index 0; const tasks []; for (let i 0; i concurrency; i) { tasks.push(run()); } async function run() { while (index chunks.length) { const current index; const chunk chunks[current]; await uploadOneChunk(fileId, current, chunk); } } await Promise.all(tasks); }并發(fā)數(shù)取多少合適我試過比較多的方案內網(wǎng)環(huán)境下6到8路并發(fā)效果最佳外網(wǎng)環(huán)境下3到4路更快。這個數(shù)字取決于服務器配置、網(wǎng)關并發(fā)限制和網(wǎng)絡帶寬。如果并發(fā)設置太高網(wǎng)關可能會直接拒絕連接設置太低又無法利用多路并行加速。每一片的上傳請求需要包含三類信息文件標識、分片序號、分片二進制數(shù)據(jù)。服務端應該以文件標識 分片序號作為冪等鍵收到重復上傳時直接返回成功這樣前端在斷點續(xù)傳時反復嘗試同一片也不會出問題。3.4 IndexedDB記錄進度刷新之后繼續(xù)傳不靠運氣斷點續(xù)傳的核心在于“狀態(tài)記錄”。前端每次上傳完一片都應該把這一片的成功狀態(tài)記錄下來。刷新頁面或者瀏覽器崩潰之后通過查詢已經(jīng)上傳的分片列表就能跳過這些分片從失敗位置繼續(xù)傳。localStorage雖然簡單但容量有限通常5MB左右而且只能存字符串。一個10GB的文件有2048片每片記錄一個ID雖然字符串不會太大但如果同時管理多個文件可能就把localStorage撐爆了。更麻煩的是localStorage的讀寫是同步的頻繁寫入會阻塞UI線程。我建議用IndexedDB來存上傳進度。它容量大、異步、性能好非常適合做斷點恢復這種場景。先簡單封裝一個存儲工具const dbName bim-upload-db; const storeName chunk-status; function openDB() { return new Promise((resolve, reject) { const request indexedDB.open(dbName, 1); request.onupgradeneeded () { const db request.result; if (!db.objectStoreNames.contains(storeName)) { const store db.createObjectStore(storeName, { keyPath: chunkId }); store.createIndex(fileId, fileId, { unique: false }); } }; request.onsuccess () resolve(request.result); request.onerror () reject(request.error); }); } async function markChunkUploaded(fileId, chunkId) { const db await openDB(); return new Promise((resolve, reject) { const tx db.transaction(storeName, readwrite); tx.objectStore(storeName).put({ fileId, chunkId, uploaded: true }); tx.oncomplete resolve; tx.onerror () reject(tx.error); }); } async function getUploadedChunks(fileId) { const db await openDB(); return new Promise((resolve, reject) { const tx db.transaction(storeName, readonly); const store tx.objectStore(storeName); const index store.index(fileId); const request index.getAll(fileId); request.onsuccess () resolve(request.result.map(item item.chunkId)); request.onerror () reject(request.error); }); }有了這個進度存儲上傳流程就變成了啟動上傳前先查IndexedDB把已經(jīng)成功上傳的分片序號過濾掉只排尚未上傳的切片進入隊列。這樣一來哪怕之前傳了一半瀏覽器崩了下次打開頁面選擇同一目錄系統(tǒng)自動識別同一批文件ID直接跳過已傳部分。這里有個必須要提醒的點IndexedDB里的記錄是“前端視角”的它代表的只是瀏覽器曾經(jīng)發(fā)出過成功響應。如果服務端在接收某一片之后、返回成功之前崩潰了前端記錄成功但實際上后端的這一片是殘缺的。所以服務端必須在每次分片上傳時做文件大小的校驗拼接時再做一次整體校驗雙保險。3.5 合并請求與整體校驗分片傳完了不代表文件沒問題所有分片都傳完之后前端需要調用一個合并接口通知服務端把臨時目錄里的分片按順序拼接成完整文件。合并請求里要帶上文件ID、總大小、總分片數(shù)、原始相對路徑。服務端在做合并之前會先檢查分片數(shù)量和大小是否吻合再執(zhí)行合并。合并完成后我強烈建議做一次文件級校驗。最簡單的方式是前端在構建文件ID時記錄文件總大小合并后由服務端返回合并后的文件大小和哈希值前端進行比對。如果要做更嚴格的校驗可以對整個文件做一次MD5計算但大文件的整體哈希計算在服務端也需要一定時間所以實際工程中我更傾向于讓前端對文件的第一個和最后一個切片做MD5作為強校驗的近似替代其余切片用大小校驗兜底。校驗通過之后目錄樹JSON和文件實體是分離的。前端在上傳分片的同時應該把目錄樹數(shù)據(jù)一并提交給服務端元數(shù)據(jù)表。服務端拿到目錄樹和數(shù)據(jù)文件后會按相對路徑在目標存儲位置重建目錄結構把文件落到對應目錄節(jié)點下。這個過程可以在合并接口里一并處理省去一次請求。4. 后端配合接口設計、合并策略與存儲規(guī)劃4.1 三個核心接口初始化、上傳分片、合并前端做得再好后端接口設計跟不上也是白搭。我們只需要三個核心接口不復雜但每一步都要考慮邊界情況。第一個是初始化接口。前端在開始上傳前先調用它把自己要傳的文件ID、文件總大小、文件名、相對路徑發(fā)給服務端。服務端返回一個uploadId并在臨時目錄下創(chuàng)建以uploadId為名的子目錄后續(xù)該文件的所有分片都存在這個目錄里。第二個是上傳分片接口。請求參數(shù)包括uploadId、chunkIndex、chunkSize二進制分片數(shù)據(jù)放在請求體中。服務端把分片寫入臨時目錄/uploadId/chunkIndex.part然后返回成功。如果這個分片已經(jīng)存在且大小一致直接返回200不上傳也沒問題。第三個是合并接口。參數(shù)包括uploadId、文件總大小、總分片數(shù)、目錄樹JSON。服務端先校驗分片完整性然后按索引順序合并寫入最終存儲路徑最后重建目錄樹。合并成功之后刪除臨時目錄返回文件元數(shù)據(jù)。我遇到的比較常見的問題是很多團隊在初始化接口里就做了大量業(yè)務判斷比如數(shù)據(jù)庫查重、權限校驗、隊列檢查結果初始化慢得像龜速。工業(yè)級場景應該把初始化接口做得盡量輕量只負責創(chuàng)建上傳會話所有業(yè)務判斷放在后續(xù)流程里異步執(zhí)行。4.2 服務端分片存儲與合并策略流式拼接比內存拼接靠譜服務端接收分片時最容易犯的錯誤是把所有分片讀入內存再拼接。一個5MB的分片乘以2048片就是10GB內存正常的服務器根本扛不住。正確的做法是分部落地。每收到一片直接使用文件流寫入磁盤路徑按uploadId 序號組織。合并時逐片打開文件使用流式方式將內容追加到目標文件尾部。Node.js里用createReadStream和createWriteStream配合管道操作每合并完一片就關閉資源內存占用始終保持恒定。合并校驗的策略也要細化。我通常會維護一個分片元信息表記錄每片的實際大小。合并前檢查兩件事已上傳分片的數(shù)量是否等于總分片數(shù)、每片的大小是否與預期一致。如果發(fā)現(xiàn)缺失或缺損返回前端一個“缺失分片列表”讓前端針對性重傳缺失的片而不是整個文件重傳。這種“按需補片”機制在弱網(wǎng)環(huán)境下尤其好用。關于磁盤規(guī)劃臨時目錄要有獨立的分區(qū)不能和系統(tǒng)目錄混在一起。之前我遇到過一次項目臨時目錄寫在系統(tǒng)盤模型上傳量一大系統(tǒng)盤被塞滿整個服務器直接無響應。臨時目錄的清理策略也要有。合并成功之后立即刪除對應分片這是最基礎的要求。還要加一個定時任務清理超過48小時仍處于未完成狀態(tài)的上傳目錄防止黑客或異常任務占滿磁盤。4.3 并發(fā)沖突與重復分片的冪等處理上傳過程中前端可能會因為網(wǎng)絡超時對同一個分片重復請求。服務端必須對這種情況做冪等處理。用uploadId chunkIndex作為主鍵如果發(fā)現(xiàn)同一個分片已經(jīng)存在且大小一致就直接返回成功不重復寫磁盤。合并操作的并發(fā)控制同樣重要。我建議用一個鎖標記來防止同一個uploadId被多個合并請求同時操作。比如在數(shù)據(jù)庫會話表里加一個mergeStatus字段合并中、合并完成、合并失敗。前端偶爾會因為超時對合并接口重復請求一對服務端看到“合并中”狀態(tài)可以適當阻塞等待看到“合并完成”直接返回結果避免合并邏輯執(zhí)行兩次產(chǎn)生臟數(shù)據(jù)。5. 國企工程場景下繞不開的坑與排查實錄5.1 網(wǎng)絡波動與斷網(wǎng)恢復指數(shù)退避重試是基礎操作國企內網(wǎng)雖然有專線但不算穩(wěn)定。特別是部分老辦公樓里的網(wǎng)絡設備高峰期經(jīng)常出現(xiàn)大量丟包。分片上傳遇到單次網(wǎng)絡失敗是常態(tài)所以前端必須有一套重試機制。我比較推薦指數(shù)退避策略第一次失敗等1秒重試第二次失敗等2秒第三次等4秒最多重試5次。如果連續(xù)5次失敗就把這個分片標記為失敗但不中斷整個上傳流程而是繼續(xù)處理其他分片失敗的分片放到隊列末尾最后統(tǒng)一補傳。實際體驗下來這種“邊傳邊補”的策略比“遇到失敗就停止整個上傳”強太多因為網(wǎng)絡抖動通常是短暫的給一小段時間它自己就恢復了。斷網(wǎng)的情況更特殊。瀏覽器檢測到網(wǎng)絡斷開時所有請求會失敗。這時候前端應該暫停整個上傳隊列監(jiān)聽online事件網(wǎng)絡恢復后重新查詢IndexedDB里的上傳狀態(tài)對未完成的分片繼續(xù)上傳。在這個過程中不需要刷新頁面體驗是連續(xù)的。5.2 瀏覽器崩潰與內存占用優(yōu)化用Web Worker把哈希計算挪到后臺瀏覽器崩潰是分片上傳最容易遇到的問題大多數(shù)原因是內存占用過高。雖然File.slice()不會一次把整個文件載入內存但部分場景下比如多個文件同時讀取、切片對象持有大量引用內存還是會快速攀升。我的經(jīng)驗是每次從磁盤讀取一個切片后立即上傳并釋放引用不要一次性把所有切片都放進一個數(shù)組里。上面給出的createChunks示例雖然是全量創(chuàng)建但實際項目中我會改為懶加載切片function getChunk(file, chunkSize, index) { const start index * chunkSize; const end Math.min(start chunkSize, file.size); return file.slice(start, end); }這樣每次只保留當前正在上傳的幾片內存占用大幅降低。如果是做全量文件哈希校驗一定不要在主線程做。一個10GB文件的全量MD5計算在瀏覽器里可能需要幾十秒甚至幾分鐘在這期間頁面會卡死。正確做法是把文件交給Web Worker在Worker線程里分片讀取并計算哈希計算完畢通過postMessage把結果傳回主線程。這樣用戶可以繼續(xù)操作界面不會出現(xiàn)“頁面已失去響應”的尷尬。5.3 老舊瀏覽器與國產(chǎn)化內核兼容降級方案要提前想好國企辦公環(huán)境里瀏覽器的實際情況可能超出技術人員想象。有大量存量電腦還在使用老版本的Chromium內核瀏覽器有些國產(chǎn)瀏覽器默認跑在兼容模式下。這些環(huán)境下webkitdirectory、IndexedDB這些特性可能是缺失的。我建議在頁面加載時做一次能力檢測分別檢測File.slice、webkitdirectory、indexedDB是否可用。如果某一項缺失就啟用降級方案。比如沒有IndexedDB就用localStorage存進度沒有webkitdirectory就不支持目錄選擇改為讓用戶選擇單個文件或壓縮包實在不行就退回最原始的整包上傳方案。雖然這些降級方案體驗差很多但總比“打開頁面什么都做不了”強。我遇到過某國企內網(wǎng)瀏覽器連File.slice都不支持的情況那套系統(tǒng)所有文件上傳都只能走傳統(tǒng)方式這是平臺底層的硬傷前端只能盡量兼容沒法完全替代。### 5.4 安全與審計模型文件是核心資產(chǎn)不能裸奔BIM模型在工程項目里屬于核心數(shù)據(jù)資產(chǎn)里面包含了完整的建筑結構信息、設備參數(shù)、工程量清單一旦泄露或者被篡改后果非常嚴重。所以上傳過程不能只想著“傳上去就行”還得考慮安全與審計。權限控制是第一層。上傳接口必須驗證用戶身份不能匿名上傳。我當時所在的系統(tǒng)對接了統(tǒng)一的身份認證平臺上傳時每次請求都要攜帶token。分片上傳接口也同樣校驗不能因為它是“部分數(shù)據(jù)”就放寬權限。操作日志是第二層。上傳開始、分片接收、合并完成、文件刪除這些操作都要記錄到日志系統(tǒng)。日志里至少要包含操作人、操作時間、文件ID、分片序號、結果狀態(tài)。國企項目的審計是要落實到具體人和具體操作的這個不能省。文件校驗是第三層。合并完成后對文件做一次病毒掃描和類型檢測。你可能會覺得奇怪模型文件怎么會有病毒但實際上從外部協(xié)作單位移交的模型包經(jīng)?；烊敫鞣N可執(zhí)行文件、宏病毒、惡意鏈接。服務端在把文件暴露給其他系統(tǒng)訪問之前必須經(jīng)過安全檢測。這不僅是技術問題更是合規(guī)問題。6. 實測效果、踩坑記錄與可復用的經(jīng)驗6.1 實測環(huán)境與最終效果在項目收尾階段我們做了幾輪壓測。測試環(huán)境是一套典型的國企內網(wǎng)配置一臺4核8GB的應用服務器一臺文件存儲服務器客戶端是普通辦公電腦。測試對象是一個約35GB的綜合BIM模型包包含5600多個文件目錄層級在5層左右。使用5MB分片、6路并發(fā)、開啟IndexedDB斷點恢復的方案整體上傳耗時大約2小時左右。期間人為中斷了兩次網(wǎng)絡每次恢復后系統(tǒng)都能自動從斷點繼續(xù)沒有出現(xiàn)重復上傳已成功的分片。服務端合并完成后校驗文件大小與源文件完全一致目錄結構也按照原始樹狀關系落到了存儲區(qū)。相比之前用普通上傳方式“傳一天斷三次”的體驗這套方案可以說是從“不可用”變成了“可用”。6.2 踩過的坑與對應解決方法第一個坑是并發(fā)數(shù)設置過高導致服務端連接數(shù)被打滿。第一次測試時我圖快直接上了20路并發(fā)結果應用服務器的連接池瞬間被耗盡所有請求全部排隊等待整個Web應用的其他功能也跟著卡住。后來把并發(fā)數(shù)降到6問題消失。這個參數(shù)最好做成配置項根據(jù)實際服務器負載動態(tài)調整。第二個坑是目錄名里包含中文、空格和特殊符號。模型交付方經(jīng)常用“B2號樓-裝修-2024-最終版”這種命名方式。如果文件ID直接用整個相對路徑拼接偶爾會出現(xiàn)空格導致的解析錯誤。解決辦法是在生成文件ID時用編碼后的相對路徑或者把路徑單獨作為一個字段存放不在ID里直接拼接。第三個坑是合并時對大文件使用同步拼接導致服務端無響應。最初的實現(xiàn)是把所有分片讀入數(shù)組再用Buffer.concat合并一個4GB的文件直接導致內存溢出。改成流式合并之后就穩(wěn)定了。這就是我前面反復強調流式處理的原因——在這個場景里它不是一個可選項而是必須項。第四個坑是清理任務誤刪未完成的上傳目錄。定時清理我最初設置的閾值是24小時但有些超大模型文件因為網(wǎng)絡原因連續(xù)傳了超過24小時結果被清理任務在合并前刪掉了。后來我把閾值改成48小時并且加了個“有進行中上傳任務”的保護判斷才徹底解決。6.3 一個很實用的小技巧服務端返回缺失分片列表最后分享一個我自己覺得特別實用的技巧。在合并接口的校驗階段服務端除了返回“失敗”之外還要返回具體的缺失或異常分片序號列表。前端拿到這個列表后只需要重傳這幾片然后再次調用合并接口。這個過程可以循環(huán)直到合并成功。這種方法在處理“某些分片損壞但不清楚是哪些”的情況下非常高效比無腦全量重傳強一個量級。我之所以一直強調這個方案里的“分片斷點目錄結構”三件套要組合起來看是因為在真實的國企工程建筑場景里這三個需求從來都是同時出現(xiàn)的。一個只支持分片上傳、不支持斷點恢復的插件在弱網(wǎng)條件下仍然會讓工程師崩潰一個支持斷點但忽略目錄結構的上傳工具傳完之后下游工具用不了等于白傳。只有把三者打通才能真正解決生產(chǎn)環(huán)境里的問題。如果你也正在處理類似的需求建議先拿一個真實的BIM模型包做測試不要用幾個小文件模擬。真實場景下的大文件數(shù)量、目錄深度、命名習慣都會逼著你把邊界情況想清楚。這套方案跑通之后后續(xù)無論是擴展上傳進度展示、增加上傳任務隊列還是對接消息通知都是在現(xiàn)有骨架上做增量開發(fā)很順手。