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