前陣子接了個老項目升級的活后臺管理系統(tǒng)還是五六年前的jQuery寫法為了長期發(fā)展老板要求整體往vue3遷。但業(yè)務(wù)不能停老頁面不能一下子推翻重寫最頭疼的是一個素材上傳模塊——用戶經(jīng)常要傳幾個G的視頻、壓縮包和設(shè)計稿以前用傳統(tǒng)form上傳動不動就超時傳到一半斷網(wǎng)就只能從頭再來。需求寫得很明確新功能必須用vue3實現(xiàn)老頁面繼續(xù)用jQuery跑同時必須支持大文件秒傳。就這么一個“新老結(jié)合”的技術(shù)場景前后磨了一周多。今天把jQuery與vue3混合開發(fā)大文件秒傳功能的整套實現(xiàn)思路、核心代碼和踩過的坑都整理出來給同樣在改造老項目的朋友一個參考。這套方案的適用面其實很寬只要你的項目正處在jQuery向vue3過渡的階段或者你負責維護一個老系統(tǒng)但需要接入現(xiàn)代化上傳體驗都應(yīng)該能從中找到能直接用的東西。1. 內(nèi)容整體設(shè)計與思路拆解1.1 混合開發(fā)場景解析為什么不是重寫而是共存很多團隊遇到老項目升級第一反應(yīng)是“找時間重寫”。但真實業(yè)務(wù)場景里老系統(tǒng)背后往往有幾十張表、幾百個接口、一堆沒人敢動的報表邏輯全量重寫周期至少按年算業(yè)務(wù)不可能停下來等你。漸進式改造就成了唯一理性選擇老頁面繼續(xù)穩(wěn)定運行新功能以vue3模塊的方式嵌入到老頁面里去。這條路聽起來簡單實際做起來有一堆細節(jié)要處理。vue3是組件化、響應(yīng)式的思維jQuery是命令式、直接操作DOM的思維兩者混在一起如果不加隔離很快就亂成一鍋粥。我的做法是把上傳這類新功能整體放到一個由vue3控制的獨立容器里jQuery只負責老頁面的交互兩者通過約定的接口通信不互相碰對方的DOM結(jié)構(gòu)。另外要認清一點混合開發(fā)不是長期目標它只是過渡期的手段。所以新增代碼盡量寫框架無關(guān)的邏輯比如文件切片、hash計算、上傳隊列這些純JS能力抽出來誰都能調(diào)將來vue3全面接管了這部分代碼可以直接復用。1.2 秒傳功能的原理與它解決的痛點很多人以為秒傳是“網(wǎng)絡(luò)快”其實秒傳根本不是傳輸而是“跳過傳輸”。文件在服務(wù)端本質(zhì)上就是一堆字節(jié)。如果兩個文件的內(nèi)容完全一致那它們的字節(jié)也完全一致。前端拿到用戶選擇的文件后先對文件內(nèi)容做一次hash計算md5或sha1得到一個指紋字符串。把這個指紋提交給服務(wù)端服務(wù)端在自己的存儲里查一下——如果之前已經(jīng)有人上傳過內(nèi)容完全相同的文件就直接返回一個“已存在”的標識前端立即提示上傳完成。整個過程中實際傳輸?shù)闹挥袔譑B的請求數(shù)據(jù)大幾G的文件瞬間完成這就是“秒傳”的真相。秒傳解決的核心痛點是“重復上傳”。在素材管理、視頻處理、文檔協(xié)作這類場景里團隊內(nèi)反復傳同一個大文件的情況非常常見。如果沒有秒傳每個用戶都要完整傳一遍既浪費帶寬又浪費時間。有了秒傳相同內(nèi)容只真正上傳一次后續(xù)所有人都是秒開。但秒傳也不是萬能的它只能處理“服務(wù)端已經(jīng)存在相同內(nèi)容”的場景。如果服務(wù)端沒有這個文件那還是得走分片上傳。所以完整的方案是秒傳優(yōu)先分片兜底兩者結(jié)合。1.3 上傳方案選型對比為什么最終選擇分片加秒傳在確定方案之前我把幾種主流上傳方式放在一起做了對比方案核心原理優(yōu)點缺點適用場景普通form上傳瀏覽器直接POST整個文件實現(xiàn)最簡單無法監(jiān)聽進度、超時容易失敗、無斷點續(xù)傳小文件、內(nèi)部工具分片上傳文件切成多塊順序上傳支持斷點續(xù)傳、失敗重傳成本低需要前后端配合分片與合并大文件、弱網(wǎng)環(huán)境斷點續(xù)傳記錄已上傳分片續(xù)傳時代跳過對網(wǎng)絡(luò)波動容忍度高需要服務(wù)端記錄分片狀態(tài)大文件、移動端弱網(wǎng)秒傳hash判重跳過實際傳輸體驗極致零等待依賴服務(wù)端已有數(shù)據(jù)重復內(nèi)容多的平臺最終方案定為“分片上傳 斷點續(xù)傳 hash秒傳”的組合。前兩步保證大文件在常規(guī)網(wǎng)絡(luò)環(huán)境下能傳得動第三步提升重復場景下的體驗。三者在前端流程里是串在一起的先算hash查重查到了直接秒傳沒查到就切分片上傳過程中記錄已上傳分片中斷后可以從斷點繼續(xù)。2. 核心細節(jié)解析與實操要點2.1 分片大小、并發(fā)數(shù)與內(nèi)存的關(guān)系分片大小沒有絕對標準但選錯了體驗差別很大。我常用的分片大小是5MB同時控制并發(fā)數(shù)為3到5。這個組合在多數(shù)辦公網(wǎng)環(huán)境下表現(xiàn)穩(wěn)定。分片太小會有問題。比如1GB文件如果按1MB切就是1024個分片每個分片都要發(fā)起一次HTTP請求光請求開銷就把帶寬優(yōu)勢抵消了。再加上服務(wù)端合并分片時文件數(shù)量多意味著排序、I/O操作更頻繁合并耗時也明顯變長。分片太大也有問題一個分片傳半天中途失敗重傳的成本高進度反饋也不夠細。并發(fā)數(shù)同樣需要控制。并發(fā)太高瀏覽器會創(chuàng)建大量連接突破服務(wù)器連接上限后反而互相爭搶帶寬單個分片傳輸速度直線下降。我做過一個簡單測試在10MB帶寬下并發(fā)3到5基本能跑滿帶寬并發(fā)上到10之后總吞吐量反而掉了。原因是分片傳輸也要經(jīng)過TCP握手、TLS協(xié)商等過程連接過多會引入大量排隊和重傳。內(nèi)存方面前端要盡量避免一次性把整個文件讀入內(nèi)存。切分片用的是File.slice方法它返回的是原始文件的引用視圖并不是真正把數(shù)據(jù)拷貝出來所以內(nèi)存壓力基本可控。真正吃內(nèi)存的是計算hash時的FileReader讀取過程這個需要分塊讀取、逐塊追加不能一次性讀整個大文件。2.2 文件指紋hash的計算策略文件hash是整個秒傳功能的地基地基歪了什么都白搭。目前工程里用得最多的是spark-md5這個庫它支持增量追加可以配合FileReader把大文件一片一片讀進內(nèi)存計算這樣內(nèi)存占用始終保持在較低水平。這里有兩個策略選擇全量計算和抽樣計算。全量計算就是讀文件的每一個字節(jié)參與hash計算準確率最高但大文件耗時長。一個500MB的文件在全量計算下可能需要5到10秒期間如果放在UI線程會直接卡死頁面。解決辦法是把計算放到Web Worker里異步執(zhí)行或者用requestIdleCallback在瀏覽器空閑時段分片處理。抽樣計算則只取文件頭部、中間、尾部的一部分字節(jié)參與hash速度很快但準確率差一些不同文件可能算出相同hash容易造成誤判。我的建議是追求體驗可以先用抽樣hash做快速判斷命中后進入分片上傳流程由服務(wù)端按完整hash做最終確認。如果項目規(guī)模不大、使用人數(shù)少直接全量計算更省心。還有一點必須注意hash計算必須基于文件內(nèi)容不能基于文件名。同一個文件重命名后內(nèi)容不變hash應(yīng)該一致反過來兩個文件內(nèi)容完全一樣但名字不同也應(yīng)該判重為同一個文件。有的實現(xiàn)圖省事直接用文件路徑加文件名算hash這種方案遇到同名不同內(nèi)容的文件就會出嚴重問題。2.3 秒傳判重、分片上傳、合并確認的三段式接口設(shè)計接口設(shè)計好不好直接決定前后端對接效率。我按照“判重、上傳、合并確認”三個階段設(shè)計了三個核心接口。第一個是hash判重接口前端計算完文件hash后調(diào)用。請求參數(shù)帶上fileHash、fileName、fileSize服務(wù)端返回文件是否存在。為了防止hash碰撞服務(wù)端可以順帶比對fileSize大小不一致就直接判不存在不用再讀文件內(nèi)容。第二個是分片上傳接口用于真實傳輸文件分片。請求參數(shù)要帶fileHash、index、total、fileName文件本體放在FormData的file字段里。服務(wù)端接收到分片后存到臨時目錄文件名建議用“fileHash_index.part”這種格式方便后續(xù)合并定位。第三個是合并確認接口當前端所有分片上傳完成后觸發(fā)。服務(wù)端根據(jù)fileHash在臨時目錄找到全部分片按index排序后流式合并成最終文件合并完成返回文件訪問路徑。這一步盡量不要做成“邊傳邊合”因為分片到達順序是亂序的邊傳邊合容易寫壞文件。2.4 并發(fā)控制與進度上報機制并發(fā)控制如果寫在每個分片請求的for循環(huán)里那等于沒有控制。我在實現(xiàn)里是手動維護一個任務(wù)隊列隊列里有待上傳的分片任務(wù)通過一個控制函數(shù)限制同時執(zhí)行的任務(wù)數(shù)每完成一個就從隊列取下一個補上。這種寫法雖然比并行丟棄全部請求要復雜一些但對網(wǎng)絡(luò)和服務(wù)端壓力都很友好斷網(wǎng)重試也能自然銜接。進度上報要區(qū)分兩個維度上傳進度和整體進度。上傳進度指的是當前分片請求的字節(jié)進度可以用axios的onUploadProgress或XHR的upload.onprogress拿到把它換算成總進度里的一個比例。整體進度則是“已成功上傳分片數(shù)/總分片數(shù)”在主線程根據(jù)任務(wù)完成數(shù)計算直接驅(qū)動vue3的進度條。兩個進度相互配合用戶看到的進度條才會既有顆粒感又有穩(wěn)定性。3. 實操過程jQuery與vue3混合開發(fā)的核心環(huán)節(jié)實現(xiàn)3.1 vue3在老頁面里安全掛載互不干擾在jQuery頁面里引入vue3最大的忌諱是直接拿vue3接管整個頁面的body。老頁面有一堆綁定在body上的事件、彈窗、定時器vue3掛載時會重建DOM這些老邏輯會瞬間失效。我的做法是單獨劃出一個上傳區(qū)域只要老頁面上留一個空的div容器在jQuery代碼里調(diào)用vue3的createApp把這個容器作為掛載點。這樣vue3只管自己的這塊DOM老頁面的其他部分繼續(xù)由jQuery掌控。// 老頁面的jQuery邏輯里在DOM ready之后掛載vue3 $(document).ready(function () { // 老業(yè)務(wù)代碼繼續(xù)跑 initOldList(); // 新上傳功能由vue3接管 import(./vue/UploadModule.js).then(({ mountUploadModule }) { mountUploadModule(#upload-module); }); });UploadModule.js內(nèi)部就是標準的vue3啟動邏輯創(chuàng)建應(yīng)用實例、掛載router或狀態(tài)、mount到指定容器。這種方式的好處是vue3模塊加載是異步的不阻礙老頁面首屏渲染掛載位置可控不會誤傷老邏輯。3.2 上傳核心邏輯抽成框架無關(guān)的純JS模塊混合開發(fā)最怕寫出來的代碼和框架綁死。我在這個項目里把上傳核心邏輯完全抽離成純JS模塊uploader.js內(nèi)部不依賴vue、不依賴jQuery只暴露幾個方法計算hash、判重、分片上傳、斷點續(xù)傳、取消任務(wù)。UI層無論是vue3還是jQuery都只是調(diào)用它然后展示狀態(tài)。這樣設(shè)計的好處很明顯第一vue3組件和jQuery頁面可以共用同一套上傳能力第二將來把整個頁面都遷到vue3時上傳邏輯不用重寫第三出問題時很好調(diào)試純JS模塊可以脫離UI單獨測試。// uploader.js 模塊導出結(jié)構(gòu) export const Uploader { calcFileHash(file, onProgress) {}, checkExist(fileHash) {}, uploadChunks(file, fileHash, options) {}, cancel() {}, getProgress() {} };// jquery老頁面直接引用不需要vue3 const uploader new Uploader(); uploader.calcFileHash(file, (p) { $(#hash-progress).text(Math.round(p * 100) %); });而在vue3組件里同樣調(diào)用Uploader只是把回調(diào)綁定到響應(yīng)式變量上UI由模板驅(qū)動。這樣一份邏輯服務(wù)兩端真正體現(xiàn)混合開發(fā)的優(yōu)雅之處。3.3 jQuery與vue3之間的通信機制兩套框架共存通信是繞不開的問題。我總結(jié)出三個層級的通信方式按場景選用。第一個是全局方法掛載。在vue3模塊啟動時把一些能力掛到window上比如window.$uploader { addFile, getStatus }。老頁面jQuery里可以直接調(diào)用這個方法把選中的文件交給vue3上傳組件處理。這個方式最簡單但要注意命名空間避免污染全局。第二個是自定義事件。vue3側(cè)通過dispatchEvent發(fā)自定義事件比如window.dispatchEvent(new CustomEvent(upload-finished, { detail: { fileHash, url } }))jQuery側(cè)用$(window).on(upload-finished, handler)監(jiān)聽。反過來jQuery觸發(fā)vue3也一樣用事件。這種方式的優(yōu)點是解耦雙方各自監(jiān)聽自己關(guān)心的事件不需要互相引用實例。第三個是共享狀態(tài)對象。定義一個小小的狀態(tài)store用vue3的reactive包裹但把store實例暴露出去。jQuery和vue3都能讀寫store里的字段vue3由于是響應(yīng)式的store變化會自動更新UI。這個適合需要頻繁同步狀態(tài)的場景比如上傳隊列、任務(wù)進度、錯誤信息等。實際項目中我大多數(shù)場景用第一種和第二種結(jié)合狀態(tài)同步用第三種。訓練下來的體會是通信越簡單越好不要讓jQuery代碼直接操作vue3內(nèi)部的ref變量封裝成方法或事件是更安全的邊界。3.4 樣式與依賴沖突的規(guī)避方案jQuery項目多數(shù)用的是老式全局CSSvue3這邊如果用element-plus這類組件庫兩邊的樣式很容易互相打架。最典型的是reset樣式和全局padding、font-family不一致vue組件在jQuery頁面里渲染出來按鈕大小、間距都和預(yù)期不一樣。我的處理方式是三條線并行。第一vue組件內(nèi)部樣式全部加scoped避免組件樣式泄漏到老頁面第二引入UI庫時不要全量引入按需加載組件和樣式減少全局污染面第三在vue3掛載容器下單獨恢復一套基礎(chǔ)樣式變量和老頁面的樣式設(shè)定做隔離。依賴沖突方面最怕的是兩套框架各自引入不同版本的公共庫。老jQuery項目可能全局掛在window.$vue3項目里如果也直接依賴jQuery就亂套了。我的原則是vue3組件里絕不直接使用全局的jQuery對象所有DOM操作和事件都走vue的方式老jQuery頁面里也不直接操作vue3內(nèi)部的DOM結(jié)構(gòu)。兩條線徹底分開不要交叉引用。4. 完整實現(xiàn)流程與關(guān)鍵代碼4.1 文件hash計算的完整實現(xiàn)hash計算我用的是spark-md5讀取分塊追加計算。下面的實現(xiàn)可以直接放到uploader.js里import SparkMD5 from spark-md5; export function calcFileHash(file, onProgress) { return new Promise((resolve, reject) { const chunkSize 2 * 1024 * 1024; // 每塊2MB const chunkCount Math.ceil(file.size / chunkSize); const spark new SparkMD5.ArrayBuffer(); const fileReader new FileReader(); let currentChunk 0; fileReader.onerror (e) { reject(new Error(文件讀取失敗)); }; fileReader.onload (e) { spark.append(e.target.result); currentChunk; if (onProgress) { onProgress(currentChunk / chunkCount); } if (currentChunk chunkCount) { loadNext(); } else { const fileHash spark.end(); resolve(fileHash); } }; function loadNext() { const start currentChunk * chunkSize; const end Math.min(start chunkSize, file.size); fileReader.readAsArrayBuffer(file.slice(start, end)); } loadNext(); }); }實際運行中500MB文件在普通PC上大約需要5到8秒完成hash計算。如果覺得這個時間太長優(yōu)先考慮把它搬進Web Worker而不是降低hash計算的準確性。Web Worker里不能直接訪問File對象需要先把文件傳到worker里但spark-md5在worker里運行完全沒問題UI線程不會卡。4.2 分片并發(fā)上傳與秒傳判定流程整個上傳流程走的是狀態(tài)機模式。每次用戶選中文件先計算hash然后做秒傳判定。判定命中就直接完成未命中就進入分片上傳中間隨時可以取消、暫停、續(xù)傳。export async function uploadFile(file, options) { const { checkUrl, uploadUrl, mergeUrl, chunkSize 5 * 1024 * 1024 } options; // 第一步計算文件hash const fileHash await calcFileHash(file, (p) { options.onHashProgress options.onHashProgress(p); }); // 第二步秒傳判定 const checkRes await axios.post(checkUrl, { fileHash, fileName: file.name, fileSize: file.size }); if (checkRes.data.data checkRes.data.data.exist) { options.onSuccess options.onSuccess({ quick: true, url: checkRes.data.data.url, fileHash }); return; } // 第三步分片上傳與斷點續(xù)傳 const totalChunks Math.ceil(file.size / chunkSize); let uploadedChunks await getUploadedChunks(fileHash); // 查詢已上傳分片 const needUploadChunks []; for (let i 0; i totalChunks; i) { if (!uploadedChunks.includes(i)) { needUploadChunks.push(i); } } await runWithConcurrency(needUploadChunks, 3, async (index) { const start index * chunkSize; const end Math.min(start chunkSize, file.size); const formData new FormData(); formData.append(file, file.slice(start, end)); formData.append(fileHash, fileHash); formData.append(index, index); formData.append(total, totalChunks); formData.append(fileName, file.name); await axios.post(uploadUrl, formData, { headers: { Content-Type: multipart/form-data } }); }); // 第四步觸發(fā)服務(wù)端合并 await axios.post(mergeUrl, { fileHash, fileName: file.name, totalChunks }); options.onSuccess options.onSuccess({ quick: false, fileHash }); }并發(fā)控制函數(shù)我用一個手寫的runWithConcurrency簡潔直觀async function runWithConcurrency(tasks, limit, worker) { const queue tasks.slice(); let running 0; return new Promise((resolve, reject) { function next() { if (queue.length 0) { if (running 0) resolve(); return; } while (running limit queue.length 0) { const task queue.shift(); running; worker(task) .then(() { running--; next(); }) .catch((err) { reject(err); }); } } next(); }); }這個寫法的好處是控制明確出錯時可以整體退出也可以按需求改成單個分片重試幾次。4.3 vue3 UI層的組件實現(xiàn)與jQuery側(cè)調(diào)用方式vue3這邊的UI我封裝成一個UploadPanel組件負責展示文件列表、進度條和狀態(tài)信息。它只通過props接收配置通過事件向外發(fā)通知完全不關(guān)心外層是jQuery還是vue3。template div classupload-panel div v-fortask in taskList :keytask.fileHash classtask-item div classtask-name{{ task.fileName }}/div div classtask-progress div classprogress-bar :style{ width: task.progress % }/div /div div classtask-status{{ task.statusText }}/div /div /div /template script setup import { ref, onMounted } from vue; import { Uploader } from ../utils/uploader.js; const taskList ref([]); function addFile(file) { const task { fileName: file.name, fileHash: , progress: 0, statusText: 等待開始 }; taskList.value.push(task); Uploader.calcFileHash(file, (p) { task.fileHash uploadState.fileHash; task.progress Math.round(p * 100); task.statusText 計算文件指紋中; }); uploadFile(file, { checkUrl: /api/file/hash/check, uploadUrl: /api/file/upload, mergeUrl: /api/file/merge }).then((res) { task.statusText res.quick ? 秒傳成功 : 上傳成功; task.progress 100; }); } defineExpose({ addFile }); /script注意組件里沒有iframe相關(guān)的代碼這里截圖的是簡化版。實際使用中如果jQuery頁面是普通script引入方式需要通過window.$uploader把addFile方法暴露出去// 啟動vue3模塊時掛載方法到window import { createApp } from vue; import UploadPanel from ./UploadPanel.vue; export function mountUploadModule(selector) { const app createApp(UploadPanel); const instance app.mount(selector); window.$uploader { addFile: (file) instance.addFile(file), getTaskList: () instance.taskList }; return instance; }jQuery側(cè)在原來的文件選擇事件里調(diào)用$(#btn-select-file).on(change, function (e) { const file e.target.files[0]; if (window.$uploader) { window.$uploader.addFile(file); } else { // 降級到老上傳邏輯或提示模塊尚未加載完成 } });這樣老頁面只是新增了一行調(diào)用原來綁定在按鈕上的其他jQuery事件完全不受影響。4.4 后端接口約定的建議寫法與偽代碼前端做完后端如果不知道按什么規(guī)范接整個方案也跑不起來。這里給出一個后端接口的偽代碼約定用Node.js風格示意邏輯同樣適用于Java、Go等其他語言。// POST /api/file/hash/check // request body: { fileHash, fileName, fileSize } // response: { code: 0, data: { exist: true, url: /files/xxx.zip } } async function checkHash(req, res) { const { fileHash, fileSize } req.body; const record await db.findFileByHash(fileHash); if (record record.size fileSize) { res.json({ code: 0, data: { exist: true, url: record.url } }); } else { res.json({ code: 0, data: { exist: false } }); } }// POST /api/file/upload // multipart/form-data 里帶 file 文件本體和其他字段 async function uploadChunk(req, res) { const { fileHash, index, total, fileName } req.body; const file req.file; const tmpPath path.join(tmpDir, ${fileHash}_${index}.part); await fs.promises.writeFile(tmpPath, file.buffer); // 記錄分片索引到redis或db方便斷點續(xù)傳查詢 await redis.sadd(upload:${fileHash}:chunks, index); res.json({ code: 0 }); }// POST /api/file/merge async function mergeChunks(req, res) { const { fileHash, fileName, totalChunks } req.body; const chunkList []; for (let i 0; i totalChunks; i) { chunkList.push(path.join(tmpDir, ${fileHash}_${i}.part)); } // 必須按index順序合并 const writeStream fs.createWriteStream(finalPath); for (const chunkPath of chunkList) { const data await fs.promises.readFile(chunkPath); writeStream.write(data); await fs.promises.unlink(chunkPath); // 合并后刪除分片 } writeStream.end(); await db.createFileRecord({ fileHash, url: finalUrl, size: stat.size }); res.json({ code: 0, data: { url: finalUrl } }); }后端一個關(guān)鍵點是分片臨時文件的清理策略防止用戶上傳到一半放棄臨時文件成了垃圾。我一般會在記錄里加上創(chuàng)建時間定時任務(wù)清理超過24小時且未合并的分片。5. 踩坑實錄與排查技巧5.1 秒傳判定成功但下載下來的文件是空的這個坑讓我排查了一個下午。現(xiàn)象是hash判重接口返回exist:true前端提示秒傳成功但用戶打開文件發(fā)現(xiàn)是0字節(jié)。最后查下來是服務(wù)端判重邏輯的問題分片合并完成后服務(wù)端只是寫了一條文件記錄但物理文件因為存儲路徑配置錯誤沒有真正落盤。判重接口卻只看數(shù)據(jù)庫記錄于是返回了錯誤的存在標記。解決方法是判重接口必須同時比對文件在存儲系統(tǒng)中的真實狀態(tài)和文件大小不能只查記錄。前端側(cè)也要加一層體驗保障——秒傳成功后如果用戶立即訪問接口返回的文件地址必須能正常打開等價于增加一次可用性探測。5.2 jQuery的contentType坑FormData被轉(zhuǎn)成字符串這個坑專門針對混合開發(fā)場景。老項目里有很多用$.ajax發(fā)請求的代碼如果你在jQuery里寫上傳分片很容易想當然$.ajax({ url: /api/file/upload, method: POST, data: formData, success: function () {} });這個寫法看起來沒問題實際上jQuery默認的contentType是application/x-www-form-urlencoded; charsetUTF-8把FormData強行轉(zhuǎn)成了表單字符串后端拿不到文件。正確的寫法必須顯式設(shè)置兩個選項$.ajax({ url: /api/file/upload, method: POST, data: formData, processData: false, // 不要處理data contentType: false, // 讓瀏覽器自動設(shè)置multipart boundary success: function () {} });如果你在vue3側(cè)用axios默認沒這個問題但混合開發(fā)里很容易出現(xiàn)“vue3里能傳切到j(luò)Query頁就傳不上去”90%都是這個原因。我后來為了統(tǒng)一把上傳請求全部走uploader.js里的XHR封裝不再讓jQuery經(jīng)手上傳邏輯。5.3 hash計算期間瀏覽器假死大文件全量計算hash確實吃CPU如果直接在主線程跑文件一大頁面就完全卡住用戶點哪都沒反應(yīng)。我的解決方案是把hash計算丟到Web Worker里。Web Worker里接收整個File對象不行但可以接收ArrayBuffer分片。主線程負責按塊讀取文件然后用postMessage傳給workerworker里調(diào)用SparkMD5追加算完再把結(jié)果傳回主線程。這樣UI線程幾乎無感期間還可以正常滾動頁面、點擊按鈕。如果項目里不方便起Worker也可以用requestIdleCallback把計算片段拆散到瀏覽器空閑時段執(zhí)行但效果比Worker差一截高峰期還是會卡。建議有條件直接上Worker。5.4 并發(fā)上傳后合并出來的文件偶爾損壞文件合并損壞的檢查方法很簡單合并完成后用hash工具重新算一遍最終文件的hash和前端算出來的fileHash比對不一致就是合并有問題。常見的合并問題有兩個。第一個是分片順序錯亂服務(wù)端沒有按index排序就拼接內(nèi)容第二個是合并過程中還在接收新的上傳分片文件被并發(fā)寫入行為弄臟。我的處理方式是在merge接口里做兩層保護第一層合并前檢查臨時目錄下的分片數(shù)量是否等于totalChunks數(shù)量不對直接拒絕合并第二層合并期間對同一個fileHash加鎖防止重復合并或邊傳邊合。這樣處理后文件損壞的問題就再沒出現(xiàn)過了。5.5 vue3掛載區(qū)域?qū)е吕蟡Query事件失效老頁面里如果某個按鈕點擊后動態(tài)往上傳區(qū)域塞DOM或者用了html()方法替換節(jié)點很容易把vue3掛載出來的DOM給換掉導致元素雖然看著還在但事件綁定全沒了。這是因為vue3的虛擬DOM會維護自己的一套節(jié)點引用jQuery直接改DOM結(jié)構(gòu)vue3完全感知不到兩邊就產(chǎn)生了不一致。我的處理方法是立一條規(guī)矩凡是被vue3接管的DOM區(qū)域老代碼一律不許直接操作需要改數(shù)據(jù)就用暴露出來的方法更新。vue3區(qū)域的DOM增刪、屬性修改都交給vue3響應(yīng)式系統(tǒng)。同時老頁面如果要銷毀上傳區(qū)域比如切換菜單不要用remove()直接刪節(jié)點而是調(diào)vue3實例的unmount方法這樣才能保證資源正確釋放。5.6 斷點續(xù)傳查詢接口要謹慎處理斷點續(xù)傳需要前端在重新上傳時查詢哪些分片已經(jīng)傳過。這個接口的數(shù)據(jù)準確性和性能非常重要如果查詢結(jié)果返回了已上傳但實際不存在的分片就會導致最終合并時缺塊。服務(wù)端在返回已上傳分片列表時最好同時校驗分片文件是否還物理存在。也就是說Redis或數(shù)據(jù)庫里記錄的分片索引只能作為參考真正的判定標準是臨時目錄里能不能找到對應(yīng)的.part文件。我在排查階段加過一個檢測邏輯凡是記錄存在但文件不存在的分片統(tǒng)一標記為未上傳重新傳一遍。這樣雖然多傳了幾個分片但至少最終文件完整不會因為臟數(shù)據(jù)導致合并失敗。寫在最后這套jQuery與vue3混合開發(fā)的大文件秒傳方案目前已經(jīng)在我們幾個老后臺頁面穩(wěn)定跑了兩個月累計上傳文件總量超過1TB秒傳命中率大概在30%左右——團隊內(nèi)部經(jīng)常傳同一批源文件這個比例帶來的帶寬節(jié)省已經(jīng)非常可觀。技術(shù)上踩過的坑不少但回過頭看核心就是兩條一是上傳邏輯絕不和UI框架綁死純JS模塊是混合開發(fā)最穩(wěn)妥的底座二是兩套框架共存時邊界要劃清楚各自管好各自的DOM和事件不要越界操作。最后分享一個我個人的小偏好一切追求“秒傳”的功能都要做好異常降級不要因為秒傳失敗就阻斷整個上傳流程。我在代碼里給秒傳判定加了一個容錯開關(guān)判重接口超時或報錯時自動降級為分片上傳雖然慢一點但用戶的文件絕不會因為一個優(yōu)化功能而傳不上去。