1. 项目概述与技术选型思考1.1 为什么还在vue2里选百度WebUploader先说结论在2024年还在维护vue2项目说明这是个存量系统大概率是企业后台、政务平台或者金融类管理系统。这类系统最大的特点就是不能随便动底层架构但安全要求又逐年升级所以“老框架老插件新加密要求”的组合特别典型。百度WebUploader这个插件很多人一听就觉得过时了。但坦白讲它在企业级场景里依然有不可替代的价值分片上传、断点续传、并发限制、MD5秒传这些能力现在很多前端上传组件要折腾半天才能实现WebUploader开箱即用。尤其在内网环境部署的系统里性能稳定、兼容性好还不需要额外依赖这几点到现在依然是硬需求。我这次接手的项目就是个典型场景vue2.6 element-ui WebUploader的存量后台需要把附件上传模块从裸HTTP明文传输升级为加密存储。需求拆开看其实有两层前端在文件上传前先做加密不能明文走网络后端存储时保留密文防止拖库后文件内容直接泄露1.2 加密方案选型的核心矛盾最初产品提需求时人员想的是“上传前用密码加密一下就行”但真正落地要考虑的事情就多了。核心矛盾在于文件体积不同加密策略必须分层一套方案打天下是不现实的。我测试过几种路线单纯用JSEncryptRSA加全部文件内容几百KB的小文件还行上MB就卡死。RSA是非对称加密密钥长、运算重不适合大量数据。单纯用CryptoJS的AES加速度没问题但密钥写死在前端等于脱裤子放屁抓包拿到密钥就能解密。AES RSA混合AES负责加密文件内容RSA负责把AES的密钥加密后传给后端。既解决性能问题也解决密钥分发问题。这是主流方案。最后定的是AES-256 RSA-2048的混合加密。AES用CBC模式PKCS7填充密钥随机生成RSA公钥来自后端接口私钥永远不出后端。这样前端就算被完全逆向也拿不到解密能力。接下来我先说封装细节然后给完整代码再讲全链路联调和坑。这个顺序能帮你先建立整体认知再抄作业的时候就不容易抄歪。2. 整体设计与技术链路拆解2.1 前端加密的完整链路整个加密上传的流程我画了个流程图在脑子里文字描述是这样的用户选择文件WebUploader接管文件队列上传前触发before-send-file钩子这里做加密每个文件随机生成一个AES密钥32字节用CryptoJS的AES-CBC加密文件二进制内容得到密文用后端下发的RSA公钥加密AES密钥得到密钥密文把密文文件和密钥密文一起post到后端后端收到后用RSA私钥解出AES密钥再用AES密钥解文件内容按业务需要存储这个链路里有个很容易被忽略的关键点不是所有场景都需要后端解出明文再存储。如果需求是“后端只存密文永不读明文”那后端不需要解密只需要把密文和密钥分开存查询时把密文交给有权限的前端自行解密。但这个项目的要求是“存储时加密使用时可控”所以我让后端解密后以密文形式入库只有业务层通过接口访问时才在内存中临时解密。这样数据库被拖了也只是密文。2.2 为什么要AES和RSA配合用生活类比来说AES像一把房间钥匙加密解密都快适合处理大件行李但房间钥匙不能直接交给别人万一被复制就完了。RSA像个保险箱慢但安全适合送“房间钥匙”这份小物件。具体到我们的链路AES密钥是随机生成的每次上传都不同即使这次被破解也影响不了历史文件RSA公钥加密AES密钥保证只有持RSA私钥的后端才能取出AES密钥网络抓包只能看到一堆无意义的base64字符文件内容加密后再进行Base64编码传输这个过程绕开了WebUploader默认的FormData裸传行为可以在过程中插入自定义校验逻辑2.3 WebUploader与vue2生命周期的绑定方式百度WebUploader原生是基于jQuery的但vue2项目里引入它要处理两个问题WebUploader实例的创建和销毁要和组件生命周期保持一致WebUploader内部操作的是真实DOMpicker按钮需要避开vue的虚拟DOM管理我的做法是把上传封装成一个独立的Uploader.vue组件在使用它的父组件里传入上传参数WebUploader实例在mounted中创建在beforeDestroy中手动销毁。这样既隔离了生命周期又能让WebUploader和vue2的数据流通过props和$emit对接。具体来说封装的好处有三点如果项目里有多个页面需要上传文件不用重复初始化WebUploader传不同的配置就行WebUploader实例的清理逻辑destroy、解绑事件集中在组件内部不会因为页面切换导致内存泄漏加密逻辑CryptoJS相关只在这个组件里被引用一旦出问题可以快速定位3. 核心细节解析与工具选型3.1 依赖引入的细节控制项目用的依赖版本很关键直接贴出来vue2.6.14webuploader0.1.9直接npm安装或者用官方dist文件也可以crypto-js4.1.1jsencrypt3.3.2这里提个坑WebUploader在npm上的包名叫webuploader但安装之后不能直接import它需要挂window。在vue2 CLI项目里我是在index.html里通过script标签引的CDN或本地文件这样能直接访问window.WebUploader避免webpack打包CommonJS时出现“WebUploader is not defined”的错误。CryptoJS的引入方式import CryptoJS from crypto-js这个库是纯JavaScript实现的不管在浏览器还是webpack环境都稳。JSEncrypt也一样import JSEncrypt from jsencrypt需要额外注意一点CryptoJS处理中文文件名时直接encrypt会报错或乱码。这是因为CryptoJS默认把字符串按UTF-8编码处理而文件名有时候编码方式不同。我是在加密前统一将文件名encodeURIComponent转了一下加密后拿到字节数组再拼接然后在FileName字段中单独加密传输避免文件名乱码的问题。3.2 加密参数配置的“为什么”先看核心加密参数配置const AESKey CryptoJS.lib.WordArray.random(32) // 32字节 256位 const AESIV CryptoJS.lib.WordArray.random(16) // 16字节 128位为什么要随机生成AESIV因为CBC模式下相同的明文和相同的密钥如果IV相同产生的密文也是相同的。攻击者可以从“相同密文”推断出“相同明文”的信息这叫做确定性加密漏洞。每次随机IV即使同一个文件上传了两次密文也完全不一样这就增加了破解难度。CBC模式和PBKDF2相关的参数我也给一下推荐值密钥长度256位32字节IV长度128位16字节填充PKCS7CryptoJS默认模式CBC编码Base64CryptoJS在代码里通过这种方式设置const encrypted CryptoJS.AES.encrypt( CryptoJS.enc.Utf8.parse(plainText), AESKey, { iv: AESIV, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 } )3.3 文件内容加密的两种姿势WebUploader在before-send-file钩子里能拿到file对象但拿到的file是WebUploader包装后的对象。加密时有两种处理方式第一种通过FileReader把file读取为ArrayBuffer然后转成WordArray交给CryptoJS处理const reader new FileReader() reader.onload function(e) { const arrayBuffer e.target.result const wordArray CryptoJS.lib.WordArray.create(arrayBuffer) const encrypted CryptoJS.AES.encrypt(wordArray, AESKey, { iv: AESIV, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }) // 后续将 encrypted.toString() 作为上传内容 } reader.readAsArrayBuffer(file)这种方式适合小文件和中等文件因为它是把整个文件读进内存再加密文件太大的话前端会有内存压力。第二种如果文件超大比如视频、压缩包WebUploader本身支持分片上传但分片加密会引入“每个分片需要独立IV和密钥”的复杂度。这个项目里我暂时没做分片级加密因为实际业务上传的文件平均都在1MB以内ArrayBuffer方式完全能扛住。如果你接手的是要传大片视频的项目我给个建议每个分片用相同的密钥但每个分片随机生成IV传输时把IV和分片密文一起发给后端后端按分片索引依次解密后拼接。这样能把“加密”和“断点续传”两个需求同时满足分片加密的代码量其实只多几十行。3.4 非对称加密保护和字段封装生成了AES密钥之后用JSEncrypt做RSA加密const encryptor new JSEncrypt() encryptor.setPublicKey(publicKey) // 后端下发的RSA公钥 const encryptedKey encryptor.encrypt(AESKey.toString(CryptoJS.enc.Base64))注意这里加密的对象是Base64编码后的AESKey字符串。AESKey是WordArray对象直接传给JSEncrypt会出问题先转成Base64字符串是稳妥的。上传时把下面几个字段封装成一个JSON对象fileNameencodeURIComponent后的原始文件名encryptedKeyRSA加密后的AES密钥Base64encryptedIVAES的IV这个我直接拼接在密文头部或者单独字段看后端解析习惯contentAES加密后的文件内容Base64timestamp时间戳可以防止重放攻击后端可选校验这段JSON用一个自定义header传给后端或者作为FormData的一个字段。我在实际项目里用的是FormData方式因为后端已经有一套MultipartFile接收逻辑直接多加了几个字段改动量小。这里有个实战技巧如果content特别大比如10MB不要直接把整个JSON塞进FormData的普通字段里而是把content作为单独的文件字段其他信息放在普通字段。这样后端拿到MultipartFile的时候就是已经加密的密文文件存储逻辑不需要改动太多。我项目里就是这么处理的把“加密后的内容”重新包装成一个Blob文件让WebUploader上传这个Blob文件。4. 实操过程与完整实现4.1 后端下发RSA公钥的接口约定第一步需要后端提供一个公钥接口。这个接口不涉及敏感操作可以设计为公开接口返回格式如下{ code: 0, data: { publicKey: -----BEGIN PUBLIC KEY-----\nMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC... } }在vue2项目的api模块里加一个方法// api/upload.js import request from /utils/request export function getRsaPublicKey() { return request({ url: /api/system/public-key, method: get }) }这里的request就是axios封装实例不用改底层逻辑正常调用就行。4.2 完整Uploader.vue组件代码下面是这个项目的核心组件我按实际代码精简后给出。先看完整结构再逐段解释。template div classuploader-container div iduploader-picker classuploader-picker选择文件/div div iduploader-list classuploader-list/div /div /template script import CryptoJS from crypto-js import JSEncrypt from jsencrypt import { getRsaPublicKey } from /api/upload export default { name: EncryptUploader, props: { accept: { type: String, default: */* }, maxSize: { type: Number, default: 20 * 1024 * 1024 }, uploadUrl: { type: String, default: /api/upload } }, data() { return { uploader: null, rsaPublicKey: } }, async mounted() { const res await getRsaPublicKey() this.rsaPublicKey res.data.publicKey this.initUploader() }, methods: { initUploader() { const _this this this.uploader window.WebUploader.create({ pick: { id: #uploader-picker, multiple: false }, accept: { title: Files, extensions: this.accept }, server: this.uploadUrl, fileVal: file, auto: false, chunked: false, duplicate: true, resize: false, compress: false, formData: { // 这里不写死业务字段因为要动态放入加密数据 } }) this.uploader.on(before-send-file, function(file) { return _this.handleBeforeSendFile(file) }) this.uploader.on(uploadSuccess, function(file, response) { _this.$emit(upload-success, file, response) }) this.uploader.on(uploadError, function(file, reason) { _this.$emit(upload-error, file, reason) }) this.uploader.on(error, function(type) { if (type Q_EXCEED_SIZE_LIMIT) { _this.$message.error(文件大小超出限制) } _this.$emit(upload-type-error, type) }) this.uploader.on(uploadComplete, function(file) { _this.$emit(upload-complete, file) }) }, handleBeforeSendFile(file) { // 返回一个PromiseWebUploader会等待它resolve后再继续 return new Promise((resolve, reject) { const reader new FileReader() reader.onload (event) { try { const arrayBuffer event.target.result const result this.encryptFile(arrayBuffer, file.name) // WebUploader通过file对象的一个扩展属性把加密后的内容传出去 file.encryptedBlob new Blob([result.content], { type: application/octet-stream }) file.encryptedFileName result.encryptedFileName file.encryptedKey result.encryptedKey file.encryptedIv result.encryptedIv file.timestamp result.timestamp this.uploader.options.server this.uploadUrl // 关键替换WebUploader内部的上传文件数据 this.overrideUploadMethod(file, result) resolve() } catch (e) { reject(e) } } reader.onerror () { reject(new Error(读取文件失败)) } reader.readAsArrayBuffer(file.source) }) }, encryptFile(arrayBuffer, fileName) { // 1. 生成AES密钥和IV const aesKey CryptoJS.lib.WordArray.random(32) const aesIv CryptoJS.lib.WordArray.random(16) // 2. 用AES加密文件内容 const wordArray CryptoJS.lib.WordArray.create(arrayBuffer) const encryptedContent CryptoJS.AES.encrypt(wordArray, aesKey, { iv: aesIv, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }).toString() // 3. 用RSA公钥加密AES密钥 const encryptor new JSEncrypt() encryptor.setPublicKey(this.rsaPublicKey) const encryptedKey encryptor.encrypt(aesKey.toString(CryptoJS.enc.Base64)) const encryptedIv encryptor.encrypt(aesIv.toString(CryptoJS.enc.Base64)) // 4. 文件名也加密 const encryptedFileName encryptor.encrypt(encodeURIComponent(fileName)) return { content: encryptedContent, encryptedKey, encryptedIv, encryptedFileName, timestamp: Date.now() } }, overrideUploadMethod(file, encryptResult) { // 这里用比较“偏门”但稳定有效的方式 // 直接操作WebUploader内部Hooks替换上传时的FormData const me this.uploader const oldSend me.uploader.options.server // 在before-send-file的Promise resolve之后修改file的上传数据 file.formData { encryptedKey: encryptResult.encryptedKey, encryptedIv: encryptResult.encryptedIv, encryptedFileName: encryptResult.encryptedFileName, timestamp: encryptResult.timestamp } // WebUploader把file.formData合并进上传请求 // 同时我们把file.source修改成加密后的Blob file.source file.encryptedBlob }, submit() { if (this.uploader) { this.uploader.upload() } } }, beforeDestroy() { if (this.uploader) { this.uploader.destroy() this.uploader null } } } /script4.3 代码里几个隐蔽但关键的点这份代码看起来逻辑不复杂但真正运行起来会踩一些隐蔽的坑我逐一说。第一个坑WebUploader默认会把file.source作为上传文件但上传时FormData里的文件名、文件内容都来自file.source。我直接把file.source file.encryptedBlob替换掉同时把file.name改成file.encryptedFileName对应的值。这样上传请求发出去时后端收到的就是密文内容和密文文件名。但WebUploader在before-send-file钩子执行完后内部会重新读取file.source的size等属性。如果你把Blob文件替换了但没更新file.size后续校验可能会报错。我在实际项目里加了一行file.size file.encryptedBlob.size这行不加的话WebUploader会出现“上传文件为空”或者进度条不动的问题。很多人在这里卡了很久其实就这么简单。第二个坑Promise.resolve后WebUploader会继续流程但没有一个官方API让你“再改一遍上传参数”。用file.formData把extra字段带过去是我尝试出来的方式。WebUploader官方文档里提到“如果要附加参数可以在uploader.option(formData)里配置”但那是对所有文件统一的。要针对单个文件动态附加就得在file对象上挂formData属性内部request方法会合并。我后来翻源码确认了这一点在webuploader.js的Request方法里确实有合并file.formData的逻辑。所以这个方法不是hack是官方预留的口子。第三个坑加密后的Base64内容会比原始文件大不少Base64编码膨胀约33%如果你在业务里对上传文件大小做了限制加解密后校验的是“加密后大小”要在组件里相应地调整校验上限。我在props里专门加了一个enableEncryptSizeLimit的配置默认不限制如果后端限制的话用加密前原始大小去判断。第四个坑CryptoJS处理ArrayBuffer时有个字节序问题。CryptoJS.lib.WordArray.create(arrayBuffer)时如果是ArrayBuffer它会按大端序读取。但ArrayBuffer本身没有字节序概念FileReader读出来就是原始字节。所以这里没问题。但如果你在某些场景下先用了DataView或TypedArray做转换就可能出现字节序翻转的问题。我的建议是不要在中途用Uint8Array转换直接用WordArray.create最稳。4.4 父组件里的使用方式封装好后父组件里这样用template div encrypt-uploader refuploaderRef acceptpdf,doc,docx,xls,xlsx,jpg,jpeg,png :max-size10 * 1024 * 1024 :upload-urluploadUrl upload-successhandleSuccess upload-errorhandleError / el-button typeprimary clicksubmitUpload上传/el-button /div /templatesubmitUpload方法methods: { submitUpload() { this.$refs.uploaderRef.submit() }, handleSuccess(file, response) { // 处理业务逻辑比如回显、保存记录 this.$message.success(上传成功) }, handleError(file, reason) { this.$message.error(上传失败) } }我在实际项目里把uploader组件的submit方法暴露给了父组件因为“选完文件后由用户点击统一上传”是后台系统的常见交互。如果你希望选完即传就在after-file-added钩子或选择文件的回调里直接调this.uploader.upload()。5. 与vue2生态的兼容性细节5.1 在vue2里处理WebUploader全局依赖WebUploader不是ESM模块npm安装后还需要在main.js里或者index.html里引入。我试验过两种方式方式一在index.html里直接加scriptscript src/static/js/webuploader.min.js/scriptpublic目录是静态资源根路径这样可以避免webpack打包时对WebUploader代码的处理问题。缺点是把全局变量挂到了window上但WebUploader本来就依赖全局这不算什么问题。方式二在组件内importimport WebUploader from webuploader这种方式在打包时会报“window is not defined”之类的错或者打出的包体积很大因为WebUploader压缩前有200KB。我建议直接用script标签方式简单粗暴稳。5.2 vue2响应式特性对WebUploader实例的影响这个点很多文章不提但我踩过很深的坑不要把WebUploader实例直接放进vue的data里。因为vue2的响应式系统会递归遍历data对象的每个属性用Object.defineProperty重写。WebUploader实例内部有大量DOM引用、事件队列和内部方法被vue代理后会导致两个问题性能下降每次属性读取都走getter拦截上传队列操作频繁时卡顿明显稳定性问题内部某些属性被拦截后可能会改变this指向导致事件回调触发异常我一开始把uploader: null放在了data里结果在上传文件列表更新时浏览器直接卡死。后来把这个变量移出data用普通对象created() { this._uploader null // 不走响应式 }之后完全没有这个性能问题了。这个细节如果你在用vue2做上传组件一定会遇到。5.3 大文件上传时vue2页面的内存管理WebUploader上传大文件时浏览器内存会明显上涨。配合CryptoJS的加密处理内存上涨幅度会更大。我这个项目用的文件不大但如果你要处理500MB以上的视频或压缩包必须注意几点加密时不要再用FileReader.readAsDataURL转Base64直接用readAsArrayBuffer更省内存加密完成后把reader和中间变量置空让浏览器能GCWebUploader的队列里不要积压太多文件尽量传完一个清理一个组件销毁时要调用uploader.destroy()并且把file.source等引用清掉否则一些浏览器会持续卡顿下面这段是我在项目里加的清理逻辑this.uploader.on(uploadComplete, function(file) { file.source null file.formData null file.encryptedBlob null // 注意不要直接删除file对象它在队列里可能还有引用 })这样每个文件传完就释放内存实测连续上传几十个文件浏览器内存基本稳定。6. 全链路联调与后端配合要点6.1 前端上传请求的实际格式前端配置完成并运行上传后F12看到的请求体大致是这样的POST https://api.example.com/api/upload HTTP/1.1 Host: api.example.com Content-Type: multipart/form-data; boundary----WebKitFormBoundary7MA4YWxkTrZu0gW ------WebKitFormBoundary7MA4YWxkTrZu0gW Content-Disposition: form-data; namefile; filenameencrypted_blob.bin Content-Type: application/octet-stream 二进制密文内容 ------WebKitFormBoundary7MA4YWxkTrZu0gW Content-Disposition: form-data; nameencryptedKey MIGfMA0GCSqGSIb3...Base64 ------WebKitFormBoundary7MA4YWxkTrZu0gW Content-Disposition: form-data; nameencryptedIv MIGfMA0GCSqGSIb3...Base64 ------WebKitFormBoundary7MA4YWxkTrZu0gW Content-Disposition: form-data; nameencryptedFileName MIGfMA0GCSqGSIb3...Base64 ------WebKitFormBoundary7MA4YWxkTrZu0gW Content-Disposition: form-data; nametimestamp 1702960585000 ------WebKitFormBoundary7MA4YWxkTrZu0gW--可以看到原始文件名不会出现在任何地方后端只看到一堆base64字符串和一个“encrypted_blob.bin”的占位文件名。这已经完全满足“防止抓包看到明文”的需求。6.2 后端接包与解密的示例逻辑如果后端是Java SpringBootController大致这么写PostMapping(/api/upload) public Result upload( RequestParam(file) MultipartFile file, RequestParam(encryptedKey) String encryptedKey, RequestParam(encryptedIv) String encryptedIv, RequestParam(encryptedFileName) String encryptedFileName, RequestParam(value timestamp, required false) Long timestamp ) throws Exception { // 1. RSA私钥解出AES密钥 // 2. AES密钥IV解出文件名 // 3. AES密钥IV解出文件内容 // 4. 按业务场景存储或返回 }Java后端解密AES密钥时用Cipher.getInstance(RSA/ECB/PKCS1Padding)对应JSEncrypt默认的RSA Padding。解密文件名时注意前端使用encodeURIComponent编码Java端需要URLDecoder.decode(decryptedFileName, UTF-8)。如果是PHP或Python后端原理类似关键是确认三件事RSA Padding模式是PKCS1AES模式是CBC、Padding是PKCS7Base64编码和解码两边一致6.3 加解密一致性验证方法联调的时候最容易出问题的是“前端加密没问题后端解出来是乱码”。我建议在正式联调前先做一次本地闭环验证用Node.js跑一次加密再用后端代码解密比对原始文件哈希。前端加密后把密文和密钥这些参数保存一份到本地或console然后在后端写个测试单元解一遍。解出来对比原始文件的MD5值如果一致链路就通了。这个验证特别重要否则你会发现一切看着正常实际解密后文件根本打不开。我整理了一张验证维度表供参考验证项前端操作后端操作结果判断AES密钥加密JSEncrypt加密后得到encryptedKeyRSA私钥解密解出的AESKey与前端一致文件内容AES-CBC加密Base64输出AES-CBC解密解出的文件MD5与原文件一致文件名encodeURIComponent加密解密URLDecoder.decode中文文件名无乱码重放攻击防护增加timestamp字段判断是否在规定窗口期过期请求拒绝6.4 部署和测试环境里的额外注意事项项目在测试环境联调时我由于公钥更新不及时吃过亏。后端的RSA密钥对是打包时生成的每次部署生成一次前端的公钥在启动时获取。如果中间件或网关缓存了接口响应前端可能拿到旧公钥后端用新私钥解不开。解决办法是每次发布时后端清一下接口缓存前端在启动时强制性拉取公钥接口加时间戳参数绕过缓存export function getRsaPublicKey() { return request({ url: /api/system/public-key?ts${Date.now()}, method: get, headers: { cache-control: no-cache } }) }另外如果使用了Nginx反代要确保这个接口没有被缓存否则上线后会出现“昨天还能传今天全报解密失败”的诡异问题。7. 常见问题与排查技巧实录7.1 WebUploader在vue2项目里选完文件没反应这个现象通常不是加密逻辑的问题而是WebUploader的picker没正确绑定。检查三点组件挂载后DOM是否真的存在mounted里init没问题但如果你在created里init就会出这个问题pick的id选择器是否指向了一个已存在且可见的元素WebUploader是基于Flash和HTML5双实现的现代环境优先走HTML5所以不需要Flash插件我在项目里碰到过一次原因是组件在弹窗里弹窗还没渲染完时就初始化了WebUploaderpicker绑不到DOM。解决办法是在弹窗的open回调或nextTick里再初始化。7.2 加密后文件打不开或解出乱码这类问题十有八九出在CryptoJS和C#或Java的AES模式参数不一致上。我见到最多的错误是前端用了CBCPkcs7后端用了ECBBase64字符串里带了换行符或多余空格切割或传递时被破坏加密后的密文经过URL传输被解析成空格这里给一个排查清单确认AES mode、padding、key、iv都一致确认RSA padding与后端一致确认Base64字符在传输过程中没有被URL编码破坏确认Blob替换后上传时的流内容就是加密后的二进制最后一句话前端加密的密文传到后端时multipart/form-data是二进制流不会做URL解码所以理论上不会出Base64被转空格的问题。但如果你走的是JSON请求体那就要注意把Base64里所有“”替换成“%2B”或者用URL-safe Base64。7.3 WebUploader在vue2下打包后报错“WebUploader is not defined”这是老生常谈的问题重新梳理一下用script标签方式引入不使用import在组件mounted里再访问window.WebUploader不要在模块顶层直接访问因为此时Script可能还没加载完如果用CDN确认引入顺序在业务代码之前我给组件里加了一个安全性检查if (!window.WebUploader) { this.$message.error(文件上传组件加载失败请刷新页面重试) return }7.4 keep-alive页面里上传组件内存泄漏vue2项目里常有用keep-alive缓存页面的场景。Uploader组件在activated和deactivated时不会销毁所以beforeDestroy可能不触发WebUploader实例会残留在内存里。我的处理方式是在deactivated钩子里主动暂停上传并释放实例deactivated() { if (this.uploader) { this.uploader.stop(true) this.uploader.destroy() this.uploader null } }, activated() { // 重新初始化 }如果你发现缓存页面反复进出后浏览器内存持续暴涨大概率就是这个问题。不用全组销毁只要在离开时destroy就行。7.5 加密后文件上传到OSS但无法在线上预览加密存储的代价就是所有依赖完整文件的预览能力都没了因为OSS里存的是密文。这个在需求阶段就要和产品确认清楚。如果需要预览有两种常见解法后端解密后通过一个临时签名的接口输出到浏览器预览预览完即失效把缩略图或视频转码流放行成明文原始文件保持密文我在项目里是先把图片压缩生成一个缩略图明文只对原始文件加密。这样列表页展示缩略图不受影响下载原文件时才走解密接口。这个方案兼顾了体验和安全推荐给你参考。8. 安全加固与扩展实践8.1 加解密过程的时间性能实测加密耗时这个数据我实测过几次给你一个参考文件大小AES-256加密耗时Base64编码耗时总耗时100KB约20ms约5ms约25ms1MB约150ms约40ms约190ms5MB约800ms约200ms约1s20MB约3.2s约800ms约4s在普通办公网络环境下多出这几秒通常是可以接受的。但如果你要上传超大文件建议在UI上做一个“加密中”的loading提示避免用户以为卡死了。8.2 再加一层自定义Header校验除了加密本身我还在项目里加了自定义Header校验前端在请求头里带一个由时间戳和AESKey摘要计算出来的签名后端做同源校验防止有人直接拿着加密后的请求重放。这个签名逻辑也很简单const sign CryptoJS.HmacSHA256(timestamp encryptedKey, aesKey.toString()).toString()后端解密后用自己的逻辑校验sign是否一致。相当于给加密链路再加了一道锁。虽然对普通业务来说RSAAES已经够用但如果你对接的是政务系统或网络安全等级保护要求高的场景这层签名是很有必要的。8.3 后续扩展方向这个方案后续还可以做几个扩展把加密从“上传加密”扩展到“下载解密”后端存密文用户下载时前端解密展示全程不在服务器落明文引入文件指纹MD5、SHA-256在上传前先做秒传判断同时保证加密后的文件指纹一致可以用来去重结合消息队列做异步解密任务避免大文件解密时阻塞主线程影响其他接口响应在我做过的系统里扩展方向往往取决于业务对文件安全重视到什么程度。加密是一个不能只做一半的事情前端加密了后端存储还暴露明文就白做了后端解密后又会把明文暴露在接口层也要加权限控制。所以全链路都要考虑到才能算完成了一次加密存储改造。最后说一点个人体会前端加密从来都不是万能的密钥、算法、传输、存储、权限每个环节都可能成为短板。但在现实项目里RSAAES混合加密已经是性价比最高的方案了——性能开销可接受、破解难度足够、实现成本也不算高。如果你和我一样在维护老项目这套东西真的可以直接复制过去用比从零搭一套安全体系省太多事了。
Vue2项目实战：WebUploader结合AES+RSA实现文件加密上传
1. 项目概述与技术选型思考1.1 为什么还在vue2里选百度WebUploader先说结论在2024年还在维护vue2项目说明这是个存量系统大概率是企业后台、政务平台或者金融类管理系统。这类系统最大的特点就是不能随便动底层架构但安全要求又逐年升级所以“老框架老插件新加密要求”的组合特别典型。百度WebUploader这个插件很多人一听就觉得过时了。但坦白讲它在企业级场景里依然有不可替代的价值分片上传、断点续传、并发限制、MD5秒传这些能力现在很多前端上传组件要折腾半天才能实现WebUploader开箱即用。尤其在内网环境部署的系统里性能稳定、兼容性好还不需要额外依赖这几点到现在依然是硬需求。我这次接手的项目就是个典型场景vue2.6 element-ui WebUploader的存量后台需要把附件上传模块从裸HTTP明文传输升级为加密存储。需求拆开看其实有两层前端在文件上传前先做加密不能明文走网络后端存储时保留密文防止拖库后文件内容直接泄露1.2 加密方案选型的核心矛盾最初产品提需求时人员想的是“上传前用密码加密一下就行”但真正落地要考虑的事情就多了。核心矛盾在于文件体积不同加密策略必须分层一套方案打天下是不现实的。我测试过几种路线单纯用JSEncryptRSA加全部文件内容几百KB的小文件还行上MB就卡死。RSA是非对称加密密钥长、运算重不适合大量数据。单纯用CryptoJS的AES加速度没问题但密钥写死在前端等于脱裤子放屁抓包拿到密钥就能解密。AES RSA混合AES负责加密文件内容RSA负责把AES的密钥加密后传给后端。既解决性能问题也解决密钥分发问题。这是主流方案。最后定的是AES-256 RSA-2048的混合加密。AES用CBC模式PKCS7填充密钥随机生成RSA公钥来自后端接口私钥永远不出后端。这样前端就算被完全逆向也拿不到解密能力。接下来我先说封装细节然后给完整代码再讲全链路联调和坑。这个顺序能帮你先建立整体认知再抄作业的时候就不容易抄歪。2. 整体设计与技术链路拆解2.1 前端加密的完整链路整个加密上传的流程我画了个流程图在脑子里文字描述是这样的用户选择文件WebUploader接管文件队列上传前触发before-send-file钩子这里做加密每个文件随机生成一个AES密钥32字节用CryptoJS的AES-CBC加密文件二进制内容得到密文用后端下发的RSA公钥加密AES密钥得到密钥密文把密文文件和密钥密文一起post到后端后端收到后用RSA私钥解出AES密钥再用AES密钥解文件内容按业务需要存储这个链路里有个很容易被忽略的关键点不是所有场景都需要后端解出明文再存储。如果需求是“后端只存密文永不读明文”那后端不需要解密只需要把密文和密钥分开存查询时把密文交给有权限的前端自行解密。但这个项目的要求是“存储时加密使用时可控”所以我让后端解密后以密文形式入库只有业务层通过接口访问时才在内存中临时解密。这样数据库被拖了也只是密文。2.2 为什么要AES和RSA配合用生活类比来说AES像一把房间钥匙加密解密都快适合处理大件行李但房间钥匙不能直接交给别人万一被复制就完了。RSA像个保险箱慢但安全适合送“房间钥匙”这份小物件。具体到我们的链路AES密钥是随机生成的每次上传都不同即使这次被破解也影响不了历史文件RSA公钥加密AES密钥保证只有持RSA私钥的后端才能取出AES密钥网络抓包只能看到一堆无意义的base64字符文件内容加密后再进行Base64编码传输这个过程绕开了WebUploader默认的FormData裸传行为可以在过程中插入自定义校验逻辑2.3 WebUploader与vue2生命周期的绑定方式百度WebUploader原生是基于jQuery的但vue2项目里引入它要处理两个问题WebUploader实例的创建和销毁要和组件生命周期保持一致WebUploader内部操作的是真实DOMpicker按钮需要避开vue的虚拟DOM管理我的做法是把上传封装成一个独立的Uploader.vue组件在使用它的父组件里传入上传参数WebUploader实例在mounted中创建在beforeDestroy中手动销毁。这样既隔离了生命周期又能让WebUploader和vue2的数据流通过props和$emit对接。具体来说封装的好处有三点如果项目里有多个页面需要上传文件不用重复初始化WebUploader传不同的配置就行WebUploader实例的清理逻辑destroy、解绑事件集中在组件内部不会因为页面切换导致内存泄漏加密逻辑CryptoJS相关只在这个组件里被引用一旦出问题可以快速定位3. 核心细节解析与工具选型3.1 依赖引入的细节控制项目用的依赖版本很关键直接贴出来vue2.6.14webuploader0.1.9直接npm安装或者用官方dist文件也可以crypto-js4.1.1jsencrypt3.3.2这里提个坑WebUploader在npm上的包名叫webuploader但安装之后不能直接import它需要挂window。在vue2 CLI项目里我是在index.html里通过script标签引的CDN或本地文件这样能直接访问window.WebUploader避免webpack打包CommonJS时出现“WebUploader is not defined”的错误。CryptoJS的引入方式import CryptoJS from crypto-js这个库是纯JavaScript实现的不管在浏览器还是webpack环境都稳。JSEncrypt也一样import JSEncrypt from jsencrypt需要额外注意一点CryptoJS处理中文文件名时直接encrypt会报错或乱码。这是因为CryptoJS默认把字符串按UTF-8编码处理而文件名有时候编码方式不同。我是在加密前统一将文件名encodeURIComponent转了一下加密后拿到字节数组再拼接然后在FileName字段中单独加密传输避免文件名乱码的问题。3.2 加密参数配置的“为什么”先看核心加密参数配置const AESKey CryptoJS.lib.WordArray.random(32) // 32字节 256位 const AESIV CryptoJS.lib.WordArray.random(16) // 16字节 128位为什么要随机生成AESIV因为CBC模式下相同的明文和相同的密钥如果IV相同产生的密文也是相同的。攻击者可以从“相同密文”推断出“相同明文”的信息这叫做确定性加密漏洞。每次随机IV即使同一个文件上传了两次密文也完全不一样这就增加了破解难度。CBC模式和PBKDF2相关的参数我也给一下推荐值密钥长度256位32字节IV长度128位16字节填充PKCS7CryptoJS默认模式CBC编码Base64CryptoJS在代码里通过这种方式设置const encrypted CryptoJS.AES.encrypt( CryptoJS.enc.Utf8.parse(plainText), AESKey, { iv: AESIV, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 } )3.3 文件内容加密的两种姿势WebUploader在before-send-file钩子里能拿到file对象但拿到的file是WebUploader包装后的对象。加密时有两种处理方式第一种通过FileReader把file读取为ArrayBuffer然后转成WordArray交给CryptoJS处理const reader new FileReader() reader.onload function(e) { const arrayBuffer e.target.result const wordArray CryptoJS.lib.WordArray.create(arrayBuffer) const encrypted CryptoJS.AES.encrypt(wordArray, AESKey, { iv: AESIV, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }) // 后续将 encrypted.toString() 作为上传内容 } reader.readAsArrayBuffer(file)这种方式适合小文件和中等文件因为它是把整个文件读进内存再加密文件太大的话前端会有内存压力。第二种如果文件超大比如视频、压缩包WebUploader本身支持分片上传但分片加密会引入“每个分片需要独立IV和密钥”的复杂度。这个项目里我暂时没做分片级加密因为实际业务上传的文件平均都在1MB以内ArrayBuffer方式完全能扛住。如果你接手的是要传大片视频的项目我给个建议每个分片用相同的密钥但每个分片随机生成IV传输时把IV和分片密文一起发给后端后端按分片索引依次解密后拼接。这样能把“加密”和“断点续传”两个需求同时满足分片加密的代码量其实只多几十行。3.4 非对称加密保护和字段封装生成了AES密钥之后用JSEncrypt做RSA加密const encryptor new JSEncrypt() encryptor.setPublicKey(publicKey) // 后端下发的RSA公钥 const encryptedKey encryptor.encrypt(AESKey.toString(CryptoJS.enc.Base64))注意这里加密的对象是Base64编码后的AESKey字符串。AESKey是WordArray对象直接传给JSEncrypt会出问题先转成Base64字符串是稳妥的。上传时把下面几个字段封装成一个JSON对象fileNameencodeURIComponent后的原始文件名encryptedKeyRSA加密后的AES密钥Base64encryptedIVAES的IV这个我直接拼接在密文头部或者单独字段看后端解析习惯contentAES加密后的文件内容Base64timestamp时间戳可以防止重放攻击后端可选校验这段JSON用一个自定义header传给后端或者作为FormData的一个字段。我在实际项目里用的是FormData方式因为后端已经有一套MultipartFile接收逻辑直接多加了几个字段改动量小。这里有个实战技巧如果content特别大比如10MB不要直接把整个JSON塞进FormData的普通字段里而是把content作为单独的文件字段其他信息放在普通字段。这样后端拿到MultipartFile的时候就是已经加密的密文文件存储逻辑不需要改动太多。我项目里就是这么处理的把“加密后的内容”重新包装成一个Blob文件让WebUploader上传这个Blob文件。4. 实操过程与完整实现4.1 后端下发RSA公钥的接口约定第一步需要后端提供一个公钥接口。这个接口不涉及敏感操作可以设计为公开接口返回格式如下{ code: 0, data: { publicKey: -----BEGIN PUBLIC KEY-----\nMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC... } }在vue2项目的api模块里加一个方法// api/upload.js import request from /utils/request export function getRsaPublicKey() { return request({ url: /api/system/public-key, method: get }) }这里的request就是axios封装实例不用改底层逻辑正常调用就行。4.2 完整Uploader.vue组件代码下面是这个项目的核心组件我按实际代码精简后给出。先看完整结构再逐段解释。template div classuploader-container div iduploader-picker classuploader-picker选择文件/div div iduploader-list classuploader-list/div /div /template script import CryptoJS from crypto-js import JSEncrypt from jsencrypt import { getRsaPublicKey } from /api/upload export default { name: EncryptUploader, props: { accept: { type: String, default: */* }, maxSize: { type: Number, default: 20 * 1024 * 1024 }, uploadUrl: { type: String, default: /api/upload } }, data() { return { uploader: null, rsaPublicKey: } }, async mounted() { const res await getRsaPublicKey() this.rsaPublicKey res.data.publicKey this.initUploader() }, methods: { initUploader() { const _this this this.uploader window.WebUploader.create({ pick: { id: #uploader-picker, multiple: false }, accept: { title: Files, extensions: this.accept }, server: this.uploadUrl, fileVal: file, auto: false, chunked: false, duplicate: true, resize: false, compress: false, formData: { // 这里不写死业务字段因为要动态放入加密数据 } }) this.uploader.on(before-send-file, function(file) { return _this.handleBeforeSendFile(file) }) this.uploader.on(uploadSuccess, function(file, response) { _this.$emit(upload-success, file, response) }) this.uploader.on(uploadError, function(file, reason) { _this.$emit(upload-error, file, reason) }) this.uploader.on(error, function(type) { if (type Q_EXCEED_SIZE_LIMIT) { _this.$message.error(文件大小超出限制) } _this.$emit(upload-type-error, type) }) this.uploader.on(uploadComplete, function(file) { _this.$emit(upload-complete, file) }) }, handleBeforeSendFile(file) { // 返回一个PromiseWebUploader会等待它resolve后再继续 return new Promise((resolve, reject) { const reader new FileReader() reader.onload (event) { try { const arrayBuffer event.target.result const result this.encryptFile(arrayBuffer, file.name) // WebUploader通过file对象的一个扩展属性把加密后的内容传出去 file.encryptedBlob new Blob([result.content], { type: application/octet-stream }) file.encryptedFileName result.encryptedFileName file.encryptedKey result.encryptedKey file.encryptedIv result.encryptedIv file.timestamp result.timestamp this.uploader.options.server this.uploadUrl // 关键替换WebUploader内部的上传文件数据 this.overrideUploadMethod(file, result) resolve() } catch (e) { reject(e) } } reader.onerror () { reject(new Error(读取文件失败)) } reader.readAsArrayBuffer(file.source) }) }, encryptFile(arrayBuffer, fileName) { // 1. 生成AES密钥和IV const aesKey CryptoJS.lib.WordArray.random(32) const aesIv CryptoJS.lib.WordArray.random(16) // 2. 用AES加密文件内容 const wordArray CryptoJS.lib.WordArray.create(arrayBuffer) const encryptedContent CryptoJS.AES.encrypt(wordArray, aesKey, { iv: aesIv, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }).toString() // 3. 用RSA公钥加密AES密钥 const encryptor new JSEncrypt() encryptor.setPublicKey(this.rsaPublicKey) const encryptedKey encryptor.encrypt(aesKey.toString(CryptoJS.enc.Base64)) const encryptedIv encryptor.encrypt(aesIv.toString(CryptoJS.enc.Base64)) // 4. 文件名也加密 const encryptedFileName encryptor.encrypt(encodeURIComponent(fileName)) return { content: encryptedContent, encryptedKey, encryptedIv, encryptedFileName, timestamp: Date.now() } }, overrideUploadMethod(file, encryptResult) { // 这里用比较“偏门”但稳定有效的方式 // 直接操作WebUploader内部Hooks替换上传时的FormData const me this.uploader const oldSend me.uploader.options.server // 在before-send-file的Promise resolve之后修改file的上传数据 file.formData { encryptedKey: encryptResult.encryptedKey, encryptedIv: encryptResult.encryptedIv, encryptedFileName: encryptResult.encryptedFileName, timestamp: encryptResult.timestamp } // WebUploader把file.formData合并进上传请求 // 同时我们把file.source修改成加密后的Blob file.source file.encryptedBlob }, submit() { if (this.uploader) { this.uploader.upload() } } }, beforeDestroy() { if (this.uploader) { this.uploader.destroy() this.uploader null } } } /script4.3 代码里几个隐蔽但关键的点这份代码看起来逻辑不复杂但真正运行起来会踩一些隐蔽的坑我逐一说。第一个坑WebUploader默认会把file.source作为上传文件但上传时FormData里的文件名、文件内容都来自file.source。我直接把file.source file.encryptedBlob替换掉同时把file.name改成file.encryptedFileName对应的值。这样上传请求发出去时后端收到的就是密文内容和密文文件名。但WebUploader在before-send-file钩子执行完后内部会重新读取file.source的size等属性。如果你把Blob文件替换了但没更新file.size后续校验可能会报错。我在实际项目里加了一行file.size file.encryptedBlob.size这行不加的话WebUploader会出现“上传文件为空”或者进度条不动的问题。很多人在这里卡了很久其实就这么简单。第二个坑Promise.resolve后WebUploader会继续流程但没有一个官方API让你“再改一遍上传参数”。用file.formData把extra字段带过去是我尝试出来的方式。WebUploader官方文档里提到“如果要附加参数可以在uploader.option(formData)里配置”但那是对所有文件统一的。要针对单个文件动态附加就得在file对象上挂formData属性内部request方法会合并。我后来翻源码确认了这一点在webuploader.js的Request方法里确实有合并file.formData的逻辑。所以这个方法不是hack是官方预留的口子。第三个坑加密后的Base64内容会比原始文件大不少Base64编码膨胀约33%如果你在业务里对上传文件大小做了限制加解密后校验的是“加密后大小”要在组件里相应地调整校验上限。我在props里专门加了一个enableEncryptSizeLimit的配置默认不限制如果后端限制的话用加密前原始大小去判断。第四个坑CryptoJS处理ArrayBuffer时有个字节序问题。CryptoJS.lib.WordArray.create(arrayBuffer)时如果是ArrayBuffer它会按大端序读取。但ArrayBuffer本身没有字节序概念FileReader读出来就是原始字节。所以这里没问题。但如果你在某些场景下先用了DataView或TypedArray做转换就可能出现字节序翻转的问题。我的建议是不要在中途用Uint8Array转换直接用WordArray.create最稳。4.4 父组件里的使用方式封装好后父组件里这样用template div encrypt-uploader refuploaderRef acceptpdf,doc,docx,xls,xlsx,jpg,jpeg,png :max-size10 * 1024 * 1024 :upload-urluploadUrl upload-successhandleSuccess upload-errorhandleError / el-button typeprimary clicksubmitUpload上传/el-button /div /templatesubmitUpload方法methods: { submitUpload() { this.$refs.uploaderRef.submit() }, handleSuccess(file, response) { // 处理业务逻辑比如回显、保存记录 this.$message.success(上传成功) }, handleError(file, reason) { this.$message.error(上传失败) } }我在实际项目里把uploader组件的submit方法暴露给了父组件因为“选完文件后由用户点击统一上传”是后台系统的常见交互。如果你希望选完即传就在after-file-added钩子或选择文件的回调里直接调this.uploader.upload()。5. 与vue2生态的兼容性细节5.1 在vue2里处理WebUploader全局依赖WebUploader不是ESM模块npm安装后还需要在main.js里或者index.html里引入。我试验过两种方式方式一在index.html里直接加scriptscript src/static/js/webuploader.min.js/scriptpublic目录是静态资源根路径这样可以避免webpack打包时对WebUploader代码的处理问题。缺点是把全局变量挂到了window上但WebUploader本来就依赖全局这不算什么问题。方式二在组件内importimport WebUploader from webuploader这种方式在打包时会报“window is not defined”之类的错或者打出的包体积很大因为WebUploader压缩前有200KB。我建议直接用script标签方式简单粗暴稳。5.2 vue2响应式特性对WebUploader实例的影响这个点很多文章不提但我踩过很深的坑不要把WebUploader实例直接放进vue的data里。因为vue2的响应式系统会递归遍历data对象的每个属性用Object.defineProperty重写。WebUploader实例内部有大量DOM引用、事件队列和内部方法被vue代理后会导致两个问题性能下降每次属性读取都走getter拦截上传队列操作频繁时卡顿明显稳定性问题内部某些属性被拦截后可能会改变this指向导致事件回调触发异常我一开始把uploader: null放在了data里结果在上传文件列表更新时浏览器直接卡死。后来把这个变量移出data用普通对象created() { this._uploader null // 不走响应式 }之后完全没有这个性能问题了。这个细节如果你在用vue2做上传组件一定会遇到。5.3 大文件上传时vue2页面的内存管理WebUploader上传大文件时浏览器内存会明显上涨。配合CryptoJS的加密处理内存上涨幅度会更大。我这个项目用的文件不大但如果你要处理500MB以上的视频或压缩包必须注意几点加密时不要再用FileReader.readAsDataURL转Base64直接用readAsArrayBuffer更省内存加密完成后把reader和中间变量置空让浏览器能GCWebUploader的队列里不要积压太多文件尽量传完一个清理一个组件销毁时要调用uploader.destroy()并且把file.source等引用清掉否则一些浏览器会持续卡顿下面这段是我在项目里加的清理逻辑this.uploader.on(uploadComplete, function(file) { file.source null file.formData null file.encryptedBlob null // 注意不要直接删除file对象它在队列里可能还有引用 })这样每个文件传完就释放内存实测连续上传几十个文件浏览器内存基本稳定。6. 全链路联调与后端配合要点6.1 前端上传请求的实际格式前端配置完成并运行上传后F12看到的请求体大致是这样的POST https://api.example.com/api/upload HTTP/1.1 Host: api.example.com Content-Type: multipart/form-data; boundary----WebKitFormBoundary7MA4YWxkTrZu0gW ------WebKitFormBoundary7MA4YWxkTrZu0gW Content-Disposition: form-data; namefile; filenameencrypted_blob.bin Content-Type: application/octet-stream 二进制密文内容 ------WebKitFormBoundary7MA4YWxkTrZu0gW Content-Disposition: form-data; nameencryptedKey MIGfMA0GCSqGSIb3...Base64 ------WebKitFormBoundary7MA4YWxkTrZu0gW Content-Disposition: form-data; nameencryptedIv MIGfMA0GCSqGSIb3...Base64 ------WebKitFormBoundary7MA4YWxkTrZu0gW Content-Disposition: form-data; nameencryptedFileName MIGfMA0GCSqGSIb3...Base64 ------WebKitFormBoundary7MA4YWxkTrZu0gW Content-Disposition: form-data; nametimestamp 1702960585000 ------WebKitFormBoundary7MA4YWxkTrZu0gW--可以看到原始文件名不会出现在任何地方后端只看到一堆base64字符串和一个“encrypted_blob.bin”的占位文件名。这已经完全满足“防止抓包看到明文”的需求。6.2 后端接包与解密的示例逻辑如果后端是Java SpringBootController大致这么写PostMapping(/api/upload) public Result upload( RequestParam(file) MultipartFile file, RequestParam(encryptedKey) String encryptedKey, RequestParam(encryptedIv) String encryptedIv, RequestParam(encryptedFileName) String encryptedFileName, RequestParam(value timestamp, required false) Long timestamp ) throws Exception { // 1. RSA私钥解出AES密钥 // 2. AES密钥IV解出文件名 // 3. AES密钥IV解出文件内容 // 4. 按业务场景存储或返回 }Java后端解密AES密钥时用Cipher.getInstance(RSA/ECB/PKCS1Padding)对应JSEncrypt默认的RSA Padding。解密文件名时注意前端使用encodeURIComponent编码Java端需要URLDecoder.decode(decryptedFileName, UTF-8)。如果是PHP或Python后端原理类似关键是确认三件事RSA Padding模式是PKCS1AES模式是CBC、Padding是PKCS7Base64编码和解码两边一致6.3 加解密一致性验证方法联调的时候最容易出问题的是“前端加密没问题后端解出来是乱码”。我建议在正式联调前先做一次本地闭环验证用Node.js跑一次加密再用后端代码解密比对原始文件哈希。前端加密后把密文和密钥这些参数保存一份到本地或console然后在后端写个测试单元解一遍。解出来对比原始文件的MD5值如果一致链路就通了。这个验证特别重要否则你会发现一切看着正常实际解密后文件根本打不开。我整理了一张验证维度表供参考验证项前端操作后端操作结果判断AES密钥加密JSEncrypt加密后得到encryptedKeyRSA私钥解密解出的AESKey与前端一致文件内容AES-CBC加密Base64输出AES-CBC解密解出的文件MD5与原文件一致文件名encodeURIComponent加密解密URLDecoder.decode中文文件名无乱码重放攻击防护增加timestamp字段判断是否在规定窗口期过期请求拒绝6.4 部署和测试环境里的额外注意事项项目在测试环境联调时我由于公钥更新不及时吃过亏。后端的RSA密钥对是打包时生成的每次部署生成一次前端的公钥在启动时获取。如果中间件或网关缓存了接口响应前端可能拿到旧公钥后端用新私钥解不开。解决办法是每次发布时后端清一下接口缓存前端在启动时强制性拉取公钥接口加时间戳参数绕过缓存export function getRsaPublicKey() { return request({ url: /api/system/public-key?ts${Date.now()}, method: get, headers: { cache-control: no-cache } }) }另外如果使用了Nginx反代要确保这个接口没有被缓存否则上线后会出现“昨天还能传今天全报解密失败”的诡异问题。7. 常见问题与排查技巧实录7.1 WebUploader在vue2项目里选完文件没反应这个现象通常不是加密逻辑的问题而是WebUploader的picker没正确绑定。检查三点组件挂载后DOM是否真的存在mounted里init没问题但如果你在created里init就会出这个问题pick的id选择器是否指向了一个已存在且可见的元素WebUploader是基于Flash和HTML5双实现的现代环境优先走HTML5所以不需要Flash插件我在项目里碰到过一次原因是组件在弹窗里弹窗还没渲染完时就初始化了WebUploaderpicker绑不到DOM。解决办法是在弹窗的open回调或nextTick里再初始化。7.2 加密后文件打不开或解出乱码这类问题十有八九出在CryptoJS和C#或Java的AES模式参数不一致上。我见到最多的错误是前端用了CBCPkcs7后端用了ECBBase64字符串里带了换行符或多余空格切割或传递时被破坏加密后的密文经过URL传输被解析成空格这里给一个排查清单确认AES mode、padding、key、iv都一致确认RSA padding与后端一致确认Base64字符在传输过程中没有被URL编码破坏确认Blob替换后上传时的流内容就是加密后的二进制最后一句话前端加密的密文传到后端时multipart/form-data是二进制流不会做URL解码所以理论上不会出Base64被转空格的问题。但如果你走的是JSON请求体那就要注意把Base64里所有“”替换成“%2B”或者用URL-safe Base64。7.3 WebUploader在vue2下打包后报错“WebUploader is not defined”这是老生常谈的问题重新梳理一下用script标签方式引入不使用import在组件mounted里再访问window.WebUploader不要在模块顶层直接访问因为此时Script可能还没加载完如果用CDN确认引入顺序在业务代码之前我给组件里加了一个安全性检查if (!window.WebUploader) { this.$message.error(文件上传组件加载失败请刷新页面重试) return }7.4 keep-alive页面里上传组件内存泄漏vue2项目里常有用keep-alive缓存页面的场景。Uploader组件在activated和deactivated时不会销毁所以beforeDestroy可能不触发WebUploader实例会残留在内存里。我的处理方式是在deactivated钩子里主动暂停上传并释放实例deactivated() { if (this.uploader) { this.uploader.stop(true) this.uploader.destroy() this.uploader null } }, activated() { // 重新初始化 }如果你发现缓存页面反复进出后浏览器内存持续暴涨大概率就是这个问题。不用全组销毁只要在离开时destroy就行。7.5 加密后文件上传到OSS但无法在线上预览加密存储的代价就是所有依赖完整文件的预览能力都没了因为OSS里存的是密文。这个在需求阶段就要和产品确认清楚。如果需要预览有两种常见解法后端解密后通过一个临时签名的接口输出到浏览器预览预览完即失效把缩略图或视频转码流放行成明文原始文件保持密文我在项目里是先把图片压缩生成一个缩略图明文只对原始文件加密。这样列表页展示缩略图不受影响下载原文件时才走解密接口。这个方案兼顾了体验和安全推荐给你参考。8. 安全加固与扩展实践8.1 加解密过程的时间性能实测加密耗时这个数据我实测过几次给你一个参考文件大小AES-256加密耗时Base64编码耗时总耗时100KB约20ms约5ms约25ms1MB约150ms约40ms约190ms5MB约800ms约200ms约1s20MB约3.2s约800ms约4s在普通办公网络环境下多出这几秒通常是可以接受的。但如果你要上传超大文件建议在UI上做一个“加密中”的loading提示避免用户以为卡死了。8.2 再加一层自定义Header校验除了加密本身我还在项目里加了自定义Header校验前端在请求头里带一个由时间戳和AESKey摘要计算出来的签名后端做同源校验防止有人直接拿着加密后的请求重放。这个签名逻辑也很简单const sign CryptoJS.HmacSHA256(timestamp encryptedKey, aesKey.toString()).toString()后端解密后用自己的逻辑校验sign是否一致。相当于给加密链路再加了一道锁。虽然对普通业务来说RSAAES已经够用但如果你对接的是政务系统或网络安全等级保护要求高的场景这层签名是很有必要的。8.3 后续扩展方向这个方案后续还可以做几个扩展把加密从“上传加密”扩展到“下载解密”后端存密文用户下载时前端解密展示全程不在服务器落明文引入文件指纹MD5、SHA-256在上传前先做秒传判断同时保证加密后的文件指纹一致可以用来去重结合消息队列做异步解密任务避免大文件解密时阻塞主线程影响其他接口响应在我做过的系统里扩展方向往往取决于业务对文件安全重视到什么程度。加密是一个不能只做一半的事情前端加密了后端存储还暴露明文就白做了后端解密后又会把明文暴露在接口层也要加权限控制。所以全链路都要考虑到才能算完成了一次加密存储改造。最后说一点个人体会前端加密从来都不是万能的密钥、算法、传输、存储、权限每个环节都可能成为短板。但在现实项目里RSAAES混合加密已经是性价比最高的方案了——性能开销可接受、破解难度足够、实现成本也不算高。如果你和我一样在维护老项目这套东西真的可以直接复制过去用比从零搭一套安全体系省太多事了。
