這事要從一個(gè)安全整改需求說起。公司內(nèi)部運(yùn)維管理系統(tǒng)一直跑在 Vue2 Element UI 這套老架構(gòu)上文件上傳模塊用的是百度 WebUploader功能沒毛病支持大文件分片、并發(fā)、斷點(diǎn)續(xù)傳甚至連 MD5 秒傳都是現(xiàn)成的。但安全部門審計(jì)時(shí)提出一條硬性要求所有存儲(chǔ)的文件不能以明文落盤。這就意味著我得在不動(dòng)現(xiàn)有業(yè)務(wù)邏輯的前提下把上傳鏈路上的文件在服務(wù)端變成密文而且還得保證后端能正常解密使用。折騰了一周多把 WebUploader、Vue2、CryptoJS、RSA 密鑰封裝這一整套串了起來中間踩了不少坑這里完整記錄下來。1. 需求拆解與加密方案選型1.1 WebUploader 憑什么還留在 Vue2 項(xiàng)目里先說選型。很多新項(xiàng)目直接用 Element UI 的 Upload 組件或者用 vue-simple-uploader但我們的情況不一樣系統(tǒng)里上傳模塊涉及大量歷史邏輯和業(yè)務(wù)綁定上傳后回調(diào)、隊(duì)列管理、失敗重試、MD5 秒傳、并發(fā)控制這些都是 WebUploader 早就固化的能力。Element UI 的 Upload 組件在分片上傳這塊幾乎沒有原生支持vue-simple-uploader 雖然功能接近但要替換意味著上傳接口、回調(diào)接口、前端隊(duì)列狀態(tài)全部重寫風(fēng)險(xiǎn)太大。WebUploader 雖然官方停止維護(hù)很久了但還是有它的價(jià)值分片上傳時(shí)自動(dòng)攜帶chunk和chunks參數(shù)后端拼接分片不需要自己設(shè)計(jì)協(xié)議threads可以控制并發(fā)數(shù)避免大文件上傳把服務(wù)器帶寬打滿內(nèi)置的md5File方法可以計(jì)算文件 MD5 實(shí)現(xiàn)秒傳。這些能力到今天依然能打只是它比較老和 Vue2 的組件化生命周期需要一點(diǎn)磨合這個(gè)后面詳細(xì)說。1.2 加密存儲(chǔ)為什么選“數(shù)字信封”方案加密存儲(chǔ)的第一個(gè)問題用什么算法加密文件內(nèi)容。直接上 RSA 嗎不行RSA 加密大文件性能太差而且有明文長(zhǎng)度限制最多加密幾百字節(jié)。直接用固定的 AES 密鑰等于用一把鑰匙開所有的鎖一旦密鑰被逆向出來歷史所有文件全部泄露密鑰輪換也很麻煩。最后選的是業(yè)界常用的“數(shù)字信封”結(jié)構(gòu)每次上傳前端隨機(jī)生成一個(gè) 32 字節(jié)的 AES 密鑰用這個(gè)密鑰加密文件內(nèi)容再用后端的 RSA 公鑰去加密這個(gè)隨機(jī) AES 密鑰把加密后的密鑰隨文件一起傳到服務(wù)端。服務(wù)端拿到密文后先用 RSA 私鑰解密出 AES 密鑰再用 AES 密鑰解密文件內(nèi)容做存儲(chǔ)或處理。這個(gè)結(jié)構(gòu)有個(gè)很實(shí)際的好處RSA 只加密幾十字節(jié)的密鑰性能開銷完全可以忽略AES 負(fù)責(zé)加密大文件速度快、安全強(qiáng)度夠每次上傳的 AES 密鑰都是隨機(jī)生成的單個(gè)文件密鑰泄露不影響其他文件。打個(gè)比方AES 密鑰就像快遞柜的取件碼RSA 公鑰就像柜子的總鑰匙每次取的碼都不一樣但只有管理員的總鑰匙才能解開。后來如果要輪換 RSA 密鑰對(duì)也只需要重新封裝一次 AES 密鑰不需要重加密歷史文件。1.3 前端加密的安全邊界必須想清楚這里必須潑一盆冷水前端加密攔不住“惡意用戶”也防不了“代碼逆向”。因?yàn)榧用苡玫?AES 密鑰在前端生成、RSA 公鑰在瀏覽器代碼里可見只要愿意任何人可以調(diào)試前端拿到密鑰流轉(zhuǎn)邏輯。那做這件事還有什么意義它的核心價(jià)值在存儲(chǔ)層文件上傳后到服務(wù)端就以密文形式落盤即使數(shù)據(jù)庫(kù)泄露、存儲(chǔ)磁盤被拖走、或者日志里不小心打出了文件內(nèi)容對(duì)方拿到的也是無法直接讀取的密文。同時(shí)它也能增強(qiáng)傳輸層的安全性即使 HTTPS 在某些內(nèi)網(wǎng)代理場(chǎng)景下被降級(jí)或繞過文件內(nèi)容本身仍然處于加密狀態(tài)。所以正確姿勢(shì)是前端加密用于“存儲(chǔ)安全”后端還必須保留獨(dú)立的鑒權(quán)體系比如上傳接口的 token 校驗(yàn)、文件類型白名單、文件大小限制、操作審計(jì)日志。這些和前端加密是互補(bǔ)關(guān)系缺一不可。在實(shí)際推行這個(gè)方案時(shí)我也和領(lǐng)導(dǎo)明確過邊界前端加密解決的核心痛點(diǎn)是“存儲(chǔ)介質(zhì)泄露不吃驚”而不承諾“端到端不可破解”。2. Vue2 項(xiàng)目里讓 WebUploader 正常跑起來2.1 依賴安裝與 jQuery 全局注入WebUploader 的老版本是強(qiáng)依賴 jQuery 的這一點(diǎn)在 Vue 工程里特別容易卡住。直接npm install jquery webuploader裝好后組件里import WebUploader from webuploader會(huì)報(bào)錯(cuò)說找不到$這是因?yàn)?WebUploader 源碼在初始化時(shí)會(huì)直接用全局的jQuery。解決辦法是在構(gòu)建工具里做一個(gè) ProvidePlugin 全局注入。我項(xiàng)目里用的是 vue.config.js配置如下// vue.config.js const webpack require(webpack); module.exports { configureWebpack: { plugins: [ new webpack.ProvidePlugin({ $: jquery, jQuery: jquery, window.jQuery: jquery }) ] } };這樣 WebUploader 在執(zhí)行時(shí)就能自動(dòng)拿到 jQuery 實(shí)例。樣式文件也別漏了在 main.js 里直接引入import webuploader/dist/webuploader.css;這里有個(gè)經(jīng)驗(yàn)WebUploader 的 npm 包版本停留在 0.1.8代碼風(fēng)格比較老ESLint 經(jīng)常會(huì)告警建議在構(gòu)建配置里把這個(gè)文件排除掉避免每次構(gòu)建刷一堆警告也防止老代碼被 babel 轉(zhuǎn)換時(shí)出幺蛾子。2.2 組件的生命周期管理WebUploader 是一個(gè)典型的 DOM 操作型組件和 Vue2 的“數(shù)據(jù)驅(qū)動(dòng)視圖”理念天然沖突。它需要一個(gè)真實(shí)的 DOM 元素作為 pick 按鈕的容器不能用 Vue 的 render 函數(shù)動(dòng)態(tài)生成。所以我的做法是在模板里先放一個(gè)固定的容器 div在 mounted 鉤子里初始化 Uploader 實(shí)例在 beforeDestroy 鉤子里銷毀。template div div iduploader-picker選擇文件/div div iduploader-list/div /div /template script export default { data() { return { uploader: null }; }, mounted() { this.initUploader(); }, beforeDestroy() { if (this.uploader) { this.uploader.destroy(); this.uploader null; } }, methods: { initUploader() { this.uploader WebUploader.create({ swf: /static/Uploader.swf, server: /api/file/upload, pick: #uploader-picker, auto: false, chunked: true, chunkSize: 2 * 1024 * 1024, threads: 3, fileVal: file, accept: { title: Files, extensions: pdf,doc,docx,xls,xlsx,zip,rar,7z, mimeTypes: * } }); // 各種事件綁定... } } };特別提醒一個(gè)和keep-alive相關(guān)的問題。如果上傳組件被包在keep-alive里組件切走時(shí)不會(huì)走beforeDestroy而是走deactivated。如果只在beforeDestroy里銷毀 Uploader切回頁(yè)面時(shí)會(huì)發(fā)現(xiàn) Uploader 實(shí)例還活著但 DOM 可能已經(jīng)被 Vue 緩存處理過會(huì)出現(xiàn)按鈕無響應(yīng)、上傳事件疊加觸發(fā)、內(nèi)存持續(xù)增長(zhǎng)的情況。正確的做法是同時(shí)監(jiān)聽 activated 和 deactivatedactivated() { if (!this.uploader) this.initUploader(); }, deactivated() { if (this.uploader) { this.uploader.destroy(); this.uploader null; } }這一點(diǎn)很關(guān)鍵我們線上就出過問題用戶在 A 頁(yè)面上傳一半切到 B 頁(yè)面再切回來原來的文件還在隊(duì)列里但又重新初始化了一個(gè) Uploader兩個(gè)實(shí)例同時(shí)綁定同一批 DOM點(diǎn)擊一次選擇按鈕彈兩次文件框。2.3 核心參數(shù)與事件梳理這里整理一個(gè)我常用的核心參數(shù)速查表后面排查問題會(huì)經(jīng)常用到。參數(shù)取值示例作用chunkedtrue是否開啟分片上傳chunkSize2 * 1024 * 1024分片大小單位字節(jié)推薦 2MB5MBthreads3并發(fā)上傳數(shù)內(nèi)網(wǎng)可以到 5外網(wǎng)建議 13fileValfile后端接收文件的字段名duplicatetrue是否允許重復(fù)文件再次入隊(duì)autofalse默認(rèn)不自動(dòng)上傳等加密處理后再觸發(fā)server/api/file/upload上傳接口地址事件方面核心的是這幾個(gè)fileQueued文件加入上傳隊(duì)列加密流程從這里開始md5FileWebUploader 附帶的方法用于計(jì)算文件 MD5實(shí)現(xiàn)秒傳判斷uploadBeforeSend每個(gè)分片發(fā)送前觸發(fā)在這里塞加密參數(shù)和鑒權(quán) tokenuploadProgress上傳進(jìn)度用于更新進(jìn)度條uploadSuccess/uploadError單文件上傳成功或失敗的最終回調(diào)uploadBeforeSend這個(gè)事件的簽名是(file, data, header)data對(duì)象就是最終發(fā)給后端的表單數(shù)據(jù)WebUploader 會(huì)把分片序號(hào)chunk、總分片數(shù)chunks自動(dòng)帶進(jìn)去我們只需要往這個(gè)對(duì)象里追加業(yè)務(wù)字段即可后端拼接分片時(shí)主要依賴這兩個(gè)字段。3. 加密存儲(chǔ)核心實(shí)現(xiàn)解析3.1 數(shù)據(jù)協(xié)議設(shè)計(jì)一次上傳請(qǐng)求帶哪些字段加密存儲(chǔ)不是簡(jiǎn)單地對(duì)文件做一個(gè) AES 加密就完事了前后端必須約定一套數(shù)據(jù)格式。我的上傳請(qǐng)求最終攜帶以下字段字段說明是否敏感file加密后的文件二進(jìn)制WebUploader 分片后自動(dòng)傳輸是但已是密文encryptKeyRSA 公鑰加密后的 AES 密鑰Base64 編碼是需 HTTPS 傳輸ivAES 加密時(shí)使用的初始向量Base64 編碼否iv 可以公開fileName原始文件名URL 編碼部分敏感建議截?cái)嗷蛎撁鬿riginalMd5原始文件的 MD5用于秒傳和校驗(yàn)否token登錄態(tài)/接口鑒權(quán) token是關(guān)于 iv 能不能明文傳這里解釋一下AES 的 iv初始向量作用是讓同一個(gè)明文在不同加密中產(chǎn)生不同的密文它本身不包含密鑰信息即使攻擊者拿到 iv沒有 AES 密鑰也無法解密。所以 iv 隨請(qǐng)求體一起傳到后端是完全安全的。服務(wù)端處理流程大致是先校驗(yàn) token再根據(jù)originalMd5判斷文件是否已存在如果存在直接返回秒傳成功如果不存在則接收分片并按chunk序號(hào)暫存等所有分片到齊后按序號(hào)拼接成完整密文再用 RSA 私鑰解密encryptKey得到 AES 密鑰最后用該密鑰和 iv 解密完整密文寫入存儲(chǔ)/對(duì)象存儲(chǔ)。3.2 前端加密中小文件最穩(wěn)妥的直接方案先講最簡(jiǎn)單也最不容易出錯(cuò)的方案適合幾十 MB 之內(nèi)的文件。核心思路是先把原始文件完整讀入內(nèi)存做一次 AES-256-CBC 加密得到加密后的二進(jìn)制 Blob再把這個(gè) Blob 交給 WebUploader。WebUploader 在傳輸層自己分片上傳后端收到的所有分片拼接起來就是完整的密文最后做一次解密即可。加密邊界和上傳分片邊界完全解耦后端不需要理解 WebUploader 分片和加密分片的對(duì)應(yīng)關(guān)系。關(guān)鍵在于 CryptoJS 處理 key 的方式。CryptoJS 的AES.encrypt第二個(gè)參數(shù)如果傳的是字符串會(huì)被當(dāng)成口令走 OpenSSL 的 KDF 派生而不是直接作為密鑰。這樣后端沒法還原同一個(gè) key。所以必須把隨機(jī)字節(jié)轉(zhuǎn)換成 WordArray 再傳import CryptoJS from crypto-js; import JSEncrypt from jsencrypt; // 生成隨機(jī) AES 密鑰32 字節(jié)即 AES-256 const aesKey CryptoJS.lib.WordArray.random(32); // 生成隨機(jī) IV16 字節(jié) const iv CryptoJS.lib.WordArray.random(16); function encryptFileToBlob(file, aesKey, iv) { return new Promise((resolve, reject) { const reader new FileReader(); reader.onload function (e) { try { const buffer e.target.result; const wordArray CryptoJS.enc.Uint8Array.parse(new Uint8Array(buffer)); const encrypted CryptoJS.AES.encrypt(wordArray, aesKey, { iv: iv, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }); // ciphertext 是 WordArray轉(zhuǎn)回 Uint8Array 生成二進(jìn)制 Blob const bytes CryptoJS.enc.Uint8Array.stringify(encrypted.ciphertext); resolve(new Blob([bytes], { type: application/octet-stream })); } catch (err) { reject(err); } }; reader.onerror reject; reader.readAsArrayBuffer(file); }); }加密完成后替換掉 WebUploader 待上傳隊(duì)列中的文件源再觸發(fā)上傳。這一步要在fileQueued事件里做this.uploader.on(fileQueued, (file) { // 先暫停自動(dòng)上傳 this.uploader.upload(); // 不要在這里調(diào)用下面說明 });實(shí)際流程要處理一下異步順序不能急著調(diào) upload要等加密完成后再上傳this.uploader.on(fileQueued, async (file) { // 先把原始文件 MD5 算出來再做秒傳判斷 const originalMd5 await this.uploader.md5File(file); file.originalMd5 originalMd5; const res await this.checkFileExist(originalMd5); if (res.exist) { // 秒傳命中跳過上傳 this.uploader.skipFile(file); return; } // 加密文件生成新的 Blob const encryptedBlob await encryptFileToBlob(file.source, aesKey, iv); // 替換文件源讓 WebUploader 上傳加密后的內(nèi)容 file.source encryptedBlob; // 記錄加密參數(shù)供 uploadBeforeSend 使用 this.currentEncryptKey aesKey.toString(CryptoJS.enc.Base64); this.currentIv iv.toString(CryptoJS.enc.Base64); this.uploader.upload(file); });這里要特別強(qiáng)調(diào)一個(gè)我在代碼里踩過的坑file.source是 WebUploader 內(nèi)部保存的源文件對(duì)象把它替換成 Blob 是可行的但必須在調(diào)用upload(file)之前完成并且在替換前不要讓它開始上傳。所以我初始化 Uploader 時(shí)把a(bǔ)uto設(shè)置為false完全由加密完成后手動(dòng)觸發(fā)上傳保證不會(huì)出現(xiàn)“還沒加密完就先上傳明文”的情況。3.3 大文件場(chǎng)景增量流式加密如果文件到了幾百 MB 甚至 GB 級(jí)別上面直接把整個(gè)文件讀進(jìn)內(nèi)存的方案就行不通了瀏覽器內(nèi)存受不了FileReader 一次讀大文件容易白屏甚至崩潰。這時(shí)需要換一種思路流式加密。CryptoJS 其實(shí)不只有AES.encrypt這種一次性接口它底層的 cipher 對(duì)象支持增量處理。用CryptoJS.algo.AES.createEncryptor(key, cfg)創(chuàng)建一個(gè)加密器然后分塊讀取原始文件每次調(diào)用process(wordArray)處理一小塊所有塊處理完后調(diào)用finalize()收尾。模式這里我推薦 CTR計(jì)數(shù)器模式因?yàn)?CTR 是流密碼不需要 padding分塊加密后的片段按順序拼接起來就是完整的連續(xù)密文后端可以一次性整體解密。這里給出一個(gè)示例的流式加密函數(shù)async function encryptFileStream(file, aesKey, iv, chunkSize 512 * 1024) { const encryptor CryptoJS.algo.AES.createEncryptor(aesKey, { iv: iv, mode: CryptoJS.mode.CTR, padding: CryptoJS.pad.NoPadding }); const encParts []; let offset 0; while (offset file.size) { const slice file.slice(offset, offset chunkSize); const buffer await readAsArrayBuffer(slice); const part encryptor.process(CryptoJS.enc.Uint8Array.parse(new Uint8Array(buffer))); // 收集的是 WordArray先轉(zhuǎn)成 Uint8Array 存入數(shù)組 encParts.push(CryptoJS.enc.Uint8Array.stringify(part)); offset chunkSize; } const finalPart encryptor.finalize(); if (finalPart.sigBytes 0) { encParts.push(CryptoJS.enc.Uint8Array.stringify(finalPart)); } return new Blob(encParts, { type: application/octet-stream }); } function readAsArrayBuffer(blob) { return new Promise((resolve, reject) { const reader new FileReader(); reader.onload () resolve(reader.result); reader.onerror reject; reader.readAsArrayBuffer(blob); }); }注意一個(gè)細(xì)節(jié)CTR 模式下所有分塊必須使用同一個(gè) iv 和同一個(gè)遞增計(jì)數(shù)器序列才能保證拼接后是連續(xù)密文。createEncryptor會(huì)維護(hù)內(nèi)部的計(jì)數(shù)器狀態(tài)分塊調(diào)用process正好滿足這一點(diǎn)。千萬不要對(duì)每個(gè)分塊重新創(chuàng)建一個(gè) encryptor 再?gòu)耐粋€(gè) iv 開始那樣每個(gè)分塊會(huì)復(fù)用相同的密鑰流等于把整個(gè)加密體系打穿這是個(gè)非常隱蔽的安全漏洞。CTR 模式還有一個(gè)兼容性問題要注意不同語(yǔ)言實(shí)現(xiàn)的 CTR 計(jì)數(shù)器字節(jié)序、溢出規(guī)則可能不完全一致。如果你后端用 Node.js 原生 crypto 的aes-256-ctr解密而前端用 CryptoJS 的 CTR兩者大部分情況下是一致的但為了穩(wěn)妥聯(lián)調(diào)時(shí)一定先用 1MB 以內(nèi)的小文件跑通確認(rèn)解密結(jié)果完全一致后再上生產(chǎn)。如果發(fā)現(xiàn)不一致要么后端也改用它自己的 CTR 實(shí)現(xiàn)要么干脆回到 CBC 模式方案整體加密后交給 WebUploader 分片上傳。我在實(shí)踐中的建議是能上 CBC 就優(yōu)先 CBC通用性最好文件太大必須做流式時(shí)才考慮 CTR并做好前后端聯(lián)調(diào)驗(yàn)證。3.4 uploadBeforeSend 里塞參數(shù)后端如何對(duì)應(yīng)解密加密完成后真正上傳時(shí)還要把加密參數(shù)帶給后端。這一步在uploadBeforeSend里處理this.uploader.on(uploadBeforeSend, (file, data, header) { // WebUploader 自動(dòng)會(huì)帶上 chunk、chunks 兩個(gè)分片參數(shù) data.fileName encodeURIComponent(file.name); data.originalMd5 file.originalMd5 || ; data.encryptKey this.currentEncryptKey; data.iv this.currentIv; // 自定義 header放鑒權(quán) token header[X-Upload-Token] this.getToken(); });后端我用 Node.js 的 multer 接收分片邏輯是每個(gè)分片保存為一個(gè)臨時(shí)文件文件名按hash_chunk命名所有分片到齊后按 chunk 序號(hào)拼接再統(tǒng)一解密。const fs require(fs); const path require(path); const crypto require(crypto); const NodeRSA require(node-rsa); const multer require(multer); const tmpDir /tmp/upload_chunks; const privateKey new NodeRSA(PRIVATE_KEY_STRING); async function handleUpload(req, res) { const { chunk, chunks, encryptKey, iv, fileName, originalMd5 } req.body; const file req.file; // multer 接收到的分片 const hash originalMd5 || ${Date.now()}_${Math.random()}; // 保存分片 const chunkPath path.join(tmpDir, ${hash}_${chunk}); fs.renameSync(file.path, chunkPath); // 如果還沒到最后一個(gè)分片直接返回 if (Number(chunk) Number(chunks) - 1) { return res.json({ ok: true, message: chunk received }); } // 所有分片到齊按 chunk 序號(hào)拼接 const chunksPaths []; for (let i 0; i Number(chunks); i) { chunksPaths.push(path.join(tmpDir, ${hash}_${i})); } const mergedBuffer Buffer.concat( chunksPaths.map((p) fs.readFileSync(p)) ); // 解密 AES 密鑰 const aesKeyBase64 privateKey.decrypt(encryptKey, utf8); const aesKey Buffer.from(aesKeyBase64, base64); const ivBuffer Buffer.from(iv, base64); // 使用 AES-256-CTR 解密文件內(nèi)容 const decipher crypto.createDecipheriv(aes-256-ctr, aesKey, ivBuffer); const decrypted Buffer.concat([decipher.update(mergedBuffer), decipher.final()]); // 寫入最終存儲(chǔ)路徑這里按業(yè)務(wù)自行調(diào)整可接 OSS / 本地磁盤 const finalPath path.join(/data/file_store, ${hash}_${fileName}); fs.writeFileSync(finalPath, decrypted); // 清理臨時(shí)分片 chunksPaths.forEach((p) fs.existsSync(p) fs.unlinkSync(p)); res.json({ ok: true, url: /file/${hash}_${fileName} }); }這里后端要注意分片拼接一定要按chunk序號(hào)排好序不能依賴到達(dá)順序。WebUploader 開了多個(gè)線程并發(fā)上傳時(shí)分片到達(dá)順序是亂的后端如果邊收邊加班最后拼出來的密文一定是壞的解密出來全是亂碼。必須全部收齊后一次性按序號(hào)拼接。3.5 秒傳、MD5 校驗(yàn)和加密的先后關(guān)系WebUploader 自帶的md5File方法可以直接算原始文件的 MD5這個(gè)能力要充分利用。完整的順序是文件入隊(duì)后先算原始 MD5再到后端查重如果服務(wù)端存在相同 MD5 的文件直接跳過上傳這就是秒傳。如果不存在再對(duì)文件做加密然后上傳密文。密文上傳成功后建議讓后端再計(jì)算一遍密文文件的 MD5連同原始文件 MD5 一起存進(jìn)元數(shù)據(jù)庫(kù)。這樣以后做完整性校驗(yàn)、文件去重、非法篡改排查都有依據(jù)。前端上傳成功后可以把這兩個(gè) MD5 一并返回給業(yè)務(wù)方方便業(yè)務(wù)側(cè)做對(duì)賬。這里容易踩的一個(gè)坑是MD5 的計(jì)算對(duì)象和加密對(duì)象必須分開理解。秒傳判斷用原始 MD5存儲(chǔ)校驗(yàn)用密文 MD5兩者不能互相替代。如果你在加密后才算 MD5那秒傳功能就廢了因?yàn)橥粋€(gè)源文件每次加密用的隨機(jī) AES 密鑰不同密文 MD5 永遠(yuǎn)不同永遠(yuǎn)無法命中秒傳反過來如果只用原始 MD5 做存儲(chǔ)校驗(yàn)無法發(fā)現(xiàn)密文在傳輸過程中被篡改的問題。所以二者都要保留。4. 常見問題與排查技巧實(shí)錄4.1 WebUploader 與 Vue2 組合的經(jīng)典坑這個(gè)模塊弄完我總結(jié)了一個(gè)高頻問題清單都是真實(shí)遇到過并排查過的。picker 點(diǎn)擊沒反應(yīng)或彈出兩次文件框大概率是 Uploader 實(shí)例沒有正確銷毀或者組件被 keep-alive 緩存后重復(fù)初始化。排查方法在控制臺(tái)打印this.uploader看看是否只有一個(gè)實(shí)例再檢查deactivated里有沒有調(diào)用destroy()。還有一種情況是模板里的 pick 容器 id 被復(fù)用比如多個(gè)組件共用了同一個(gè) dom id導(dǎo)致 WebUploader 綁定到了錯(cuò)誤節(jié)點(diǎn)。上傳事件疊加一個(gè)文件觸發(fā)多次回調(diào)這是典型的 Uploader 實(shí)例泄漏。每次進(jìn)頁(yè)面都新建了一個(gè)實(shí)例但沒有銷毀舊的新舊實(shí)例同時(shí)監(jiān)聽同一個(gè)隊(duì)列導(dǎo)致一次上傳觸發(fā)多個(gè)uploadSuccess。解決方法是嚴(yán)格遵循 activated/deactivated 或 mounted/beforeDestroy 的成對(duì)生命周期。構(gòu)建后控制臺(tái)報(bào) jQuery is not definedWebUploader 源碼在運(yùn)行時(shí)會(huì)訪問全局 jQuery。如果 ProvidePlugin 配置寫錯(cuò)或者構(gòu)建緩存沒刷新就容易出這個(gè)問題?？梢試L試在入口文件 main.js 里顯式掛載一次import $ from jquery; window.jQuery $; window.$ $;上傳的文件在服務(wù)端是 0 字節(jié)多半是fileVal和后端解析字段不匹配。比如前端默認(rèn)字段名是file但后端 multer 接收的是uploadFile就會(huì)拿到空。檢查fileVal參數(shù)和后端接口的解析字段是否一致。老組件被安全掃描報(bào)告漏洞WebUploader 畢竟停止維護(hù)了安全掃描工具經(jīng)常把它標(biāo)記為“脆弱的 JavaScript 庫(kù)”。我的建議是不要把它暴露在公網(wǎng)通過內(nèi)網(wǎng)訪問或者網(wǎng)關(guān)層做白名單前端渲染文件名時(shí)不要用 innerHTML 拼接避免 XSS對(duì)外部上傳做大小和類型限制。如果是面向互聯(lián)網(wǎng)的公開產(chǎn)品還是優(yōu)先換更現(xiàn)代化的上傳組件。4.2 加密鏈路里的隱藏坑加密本身也有一堆不容易察覺的坑這里挑幾個(gè)我最想提醒的。CryptoJS 把字符串當(dāng) passphrase 而不是 key這是最容易犯的錯(cuò)誤。CryptoJS.AES.encrypt(data, myPassword)這種寫法CryptoJS 會(huì)用myPassword作為口令走 OpenSSL 的 EVP_BytesToKey 派生規(guī)則生成密鑰和鹽。問題是同一個(gè)口令每次派生出來的密鑰都是隨機(jī)的因?yàn)辂}是隨機(jī)生成的后端根本沒法用同樣的字符串還原出同一個(gè)密鑰。所以密鑰必須是隨機(jī)生成的 WordArray 或字節(jié)數(shù)組加密解密兩端使用同樣的字節(jié)數(shù)據(jù)。我在聯(lián)調(diào)時(shí)卡了很久才發(fā)現(xiàn)這個(gè)。WordArray 和 Uint8Array 互轉(zhuǎn)的字節(jié)序問題CryptoJS 的 WordArray 內(nèi)部是按大端存儲(chǔ)的 32 位整數(shù)直接轉(zhuǎn)成 Uint8Array 時(shí)很容易弄錯(cuò)字節(jié)序。最穩(wěn)妥的方式是使用 CryptoJS 自帶的CryptoJS.enc.Uint8Array.parse和CryptoJS.enc.Uint8Array.stringify不要自己寫循環(huán)反轉(zhuǎn)省得踩大小端坑。加密后內(nèi)容用 Base64 字符串落入 Blob體積膨脹 33%如果直接把 CryptoJS 加密結(jié)果的toString()轉(zhuǎn)成 Base64 字符串再生成 Blob文件會(huì)大 1/3后端還得先解 Base64 再解密。正確做法是取encrypted.ciphertext這個(gè) WordArray轉(zhuǎn)成原始二進(jìn)制再生成 Blob。這樣密文體積和原始文件幾乎一致只多了 16 字節(jié) padding性能也更好。后端解密出來是亂碼但沒報(bào)錯(cuò)一般有兩個(gè)原因一是分片拼接順序錯(cuò)了按到達(dá)順序拼接而不是按 chunk 序號(hào)拼接二是前后端使用的加密模式和填充不一致比如前端 CBC Pkcs7后端按 ECB 解密。排查時(shí)先不看解密結(jié)果直接把前端加密后的密文文件下載下來在本地用同樣的 key/iv/mode 解密一遍如果能解出來問題基本就在后端參數(shù)傳遞上。下面是速查表現(xiàn)象可能原因解決辦法上傳失敗請(qǐng)求返回 500后端分片拼接邏輯錯(cuò)誤檢查 chunks 參數(shù)確保按 chunk 序號(hào)排序拼接解密后文件亂碼加密模式/填充方式前后端不一致統(tǒng)一使用 CBC Pkcs7參數(shù)從前端傳后端并打印日志比對(duì)大文件上傳時(shí)頁(yè)面卡頓FileReader 全量讀入內(nèi)存改用流式加密或把加密邏輯放到 Web Worker秒傳永遠(yuǎn)不生效加密后才計(jì)算 MD5加密前先算原始文件 MD5 并調(diào)用秒傳接口密文文件比源文件大很多Base64 編碼后落盤使用二進(jìn)制 Blob不要轉(zhuǎn) Base64 字符串落盤上傳成功后后端無法打開文件AES key 被當(dāng)字符串傳了確保前后端用字節(jié)形式傳遞和解析 key4.3 加密性能優(yōu)化與后續(xù)擴(kuò)展加密操作確實(shí)會(huì)消耗 CPU尤其是流式加密大文件時(shí)遍歷文件每一塊都要做一次 AES 計(jì)算。實(shí)測(cè)下來普通辦公機(jī) 2MB 分片做 CBC 加密大概十幾到幾十毫秒基本無感但如果是幾百 MB 的文件多次加密耗時(shí)累計(jì)起來會(huì)讓用戶感覺到“卡在選擇文件后的處理階段”。優(yōu)化方向有兩個(gè)一是把加密放到 Web Worker 里不阻塞 UI 線程二是把文件讀取和加密的 chunkSize 適當(dāng)調(diào)大減少 process 調(diào)用次數(shù)512KB 是平衡點(diǎn)再大反而容易造成內(nèi)存抖動(dòng)。對(duì)于后續(xù)擴(kuò)展我建議把 RSA 公鑰做成可配置的不同業(yè)務(wù)模塊可以使用不同的密鑰對(duì)甚至做到密鑰輪換時(shí)只需將舊的 AES 密鑰用新公鑰重新封裝一次文件內(nèi)容不需要重新加密。這個(gè)操作在數(shù)字信封架構(gòu)下非常自然也是我選這個(gè)方案最滿意的一點(diǎn)。寫在最后的一個(gè)經(jīng)驗(yàn)這一套改造做下來最深的體會(huì)是加密本身并不難難點(diǎn)在于把“老的組件生命周期”和“新的加密職責(zé)”有效地黏合起來。WebUploader 雖然老但它分片、并發(fā)、秒傳的上傳骨架是穩(wěn)定的只要做到實(shí)例隨組件創(chuàng)建和銷毀、加密完成后替換文件源、上傳參數(shù)通過 uploadBeforeSend 完整傳遞整個(gè)鏈路就能穩(wěn)定跑在生產(chǎn)環(huán)境。這個(gè)方案上線后已經(jīng)跑了兩個(gè)業(yè)務(wù)季度除了最開始聯(lián)調(diào)時(shí)踩過的 iv 和 chunk 拼接問題加密鏈路沒有再出過事故。如果你也在 Vue2 項(xiàng)目里遇到類似訴求可以照著我這套思路先搭一個(gè)小 demo 驗(yàn)證遇到具體問題歡迎回來對(duì)照速查表排查。