AES-JS 这个名字玩前端的老哥们应该不陌生——它就是那个让 JavaScript 世界里能直接做 AES 加解密的纯 JS 实现。我最早接触它是给某电商项目做用户敏感字段脱敏登录密码、手机号、身份证这一类信息在前端表单里明文放着总让人觉得不踏实后端接口又不可能为每个小项目单独改造上线。于是我用 AES-JS 在浏览器端先把数据加密再走常规接口提交后端拿到密文后统一解密入库一条链路就给敏感数据加了把锁。说实话这个库能做的不只是“加密一段字符串”。它解决的是前端数据裸奔的普遍焦虑localStorage 里存了 token、草稿箱里有未提交的订单、配置文件里躺着数据库地址——这些东西只要落盘就是明文一台被木马光顾过的电脑或一个浏览器插件就能把它们读走。AES-JS 的价值就是把这些本该见不得光的数据在浏览器内存里就转成密文让即使有人打开 DevTools 也看不到明文。这篇文章我把密钥选择、IV 处理、模式选型、前后端联调这些坑一次性捋清楚适合刚上手加密的前端开发、写过几个接口想加强安全性的全栈工程师以及所有被“数据裸奔恐慌”困扰的个人项目维护者。1. 先搞清楚边界AES-JS 到底守住哪道门1.1 一句话认识 AES-JSAES-JS 是 AESAdvanced Encryption Standard高级加密标准在 JavaScript 世界的落地实现。AES 本身是取代 DES 的对称加密算法密钥长度支持 128、192、256 三种按目前公开的密码学分析AES-128 的暴力破解在可预见的时间尺度内都不可行所以“高级”指的是算法强度等级不是“高级玩法”那种高级。对称加密就一个特点加密解密用同一把钥匙。这跟非对称加密公钥加密私钥解密正好相反。所以 AES-JS 的使用逻辑从来不是“自己一个人偷偷加密就完事”而是“有密钥的双方共用一把钥匙互通密文”。小到两个页面之间传个敏感字符串大到前端加密后端解密的完整链路本质上都是这把钥匙在流动。我见过不少刚接触加密的开发者犯过一个认知错误以为浏览器端加密了网络传输就安全了。这是不对的。AES 加密的是“数据内容”让数据即使被截获也读不出原意而 HTTPS 保护的是“传输通道”防止数据在链路上被完整截获。两者根本不在一个层面不能互相替代。1.2 三条真实使用场景那 AES-JS 到底适合干什么基于我的实际项目经验大概三件事最有价值。第一件登录和支付类表单的敏感字段前置加密。表单里的密码、银行卡号、手机号在点击提交按钮之前先用 JS 加密成密文再作为请求参数发出。后端拿到密文后解密出明文再做业务校验。这样即使有人用抓包工具盯着接口看看到的也只是一串密文而不是用户密码本身。不过要强调这是一种“纵深防御”手段绝不能因为有了前端加密就不上 HTTPS——因为防截获靠的还是传输层。第二件浏览器本地缓存保护。localStorage、sessionStorage、IndexedDB 里的数据都是明文落盘的。比如有些单页应用把用户信息、权限标识、购物车快照直接塞进 localStoragetoken 有效期还设得很长。一旦本机染上恶意插件或被人直接翻浏览器缓存文件这些数据等于白送。用 AES-JS 把值加密后再 setItem取用时再解密成本很低但能把“裸奔”变成“有壳”。第三件配置文件与导出文件的保护。有些企业项目会通过前端导出包含敏感信息的 Excel 或 CSV或者在前端代码里内置一些外部系统的访问密钥、API 地址。这些场景下用 AES-JS 在文件生成或存储环节加密一层虽然不是绝对安全但能让偶然拿到文件的人无法直接使用数据。1.3 为什么选 AES-JS而不是其他方案选型这个问题我经历过挺多纠结。前端做加密其实有四条路可走自己手写算法、用浏览器原生的 WebCrypto API、用 aes-js 这种纯 JS 库、或者用功能更全的封装库比如社区里最常见的 CryptoJS。自己手写算法这条路首先排除。AES 的 S 盒、轮常量、列混合变换每一个环节都经过极其严格的设计和安全性审查业余选手自己写能跑通就很不错了还想保证没有侧信道漏洞不如直接去抢银行更省事。然后是 WebCrypto API。这是浏览器私生子所有主流现代浏览器都支持性能是原生 C 级的还支持 AES-GCM 这种带认证加密的模式。但它有两个让人头疼的问题第一API 设计很繁琐生成密钥、导入密钥、加解密、导出密钥每一步都要写好几行异步代码第二它只在安全上下文里可用部分企业内网环境、低版本浏览器和 WebView 场景都不支持。我做过一个要兼容老旧收银机的项目WebCrypto 直接被排除了。AES-JS 和 CryptoJS 这类纯 JS 库的优势在哪零依赖、随处可跑、接口简单字符串一把梭进去就能出密文。CryptoJS 用的人尤其多因为它顺手封装了 WordArray、Base64、Hex 等编码转换写起来非常舒服。而 aes-js 则更轻量、更底层适合需要自己控制字节流细节的高级用法。对大多数项目来说我会优先建议从 CryptoJS 这种封装库入手因为它更贴近业务代码量最少等真正有性能苛求或字节级控制需求时再切 aes-js。用个生活类比AES-JS 和 CryptoJS 就像一把开箱即用的标准保险箱说明书写得很清楚按钮一按就锁上WebCrypto 是给你一堆钢板焊条让你自己焊一口保险柜能焊出个好东西但大多数人的焊工都用不上手写算法则相当于想自己发明一套锁芯——听着很硬核实际上等于把自己的钱从一个坑搬进另一个坑。2. 避坑前置课密钥、模式、IV、Padding 四个词必须吃透很多人上来就抄网上的代码跑通就以为会了然后上线后踩坑踩到怀疑人生。加密这件事不懂底层参数就像不懂交通规则就上路出事只是时间问题。所以这节先把四个最核心的概念讲透。2.1 密钥长度与口令派生AES 支持三种密钥长度128、192、256 位对应字节数就是 16、24、32 字节。很多人的直觉是“越长越安全”所以闭眼选 256。但实际上 AES-128 的暴力破解难度已经远超任何现实攻击能力128 位密钥意味着 2 的 128 次方种可能用全球所有算力加起来穷举也是天文数字级别。选 256 唯一的收获是心理安慰代价是性能更慢轮数从 10 轮增加到 14 轮以及密钥管理的字节数更多更容易出错。对绝大多数业务场景AES-128 完全够用。真正的危险不是密钥太短而是密钥太弱。有的同学直接把123456这种字符串当 key 传进去或者把password这种词 hash 一下当密钥——这类密钥空间太小密文稍微多点就能被字典攻击打穿。正确的做法是要么用密码学安全的随机数生成 16 字节随机字节当密钥要么从一个高强度口令通过 PBKDF2/scrypt 这类密钥派生函数生成密钥。举个例子用口令派生密钥// 这是概念示例实际投产建议用专门库做PBKDF2 // 口令MyStr0ng!Passphrase // 盐随机生成至少16字节 // 迭代次数至少10万次 // 输出16字节的AES-128密钥注意 PBKDF2 的“盐”和“迭代次数”也是参数盐要随机且每次不同迭代次数影响暴力破解成本太低会被秒破太高则浏览器端卡顿明显我实测下来 10 万次在主流 PC 上大概耗时几十到两百毫秒是体验和安全的较好平衡点。2.2 加密模式怎么选CBC 还是 CTR同一个 AES 加密算法可以套不同的“工作模式”。模式决定了分组密码如何加密多于一组的数据。主流的模式无非 ECB、CBC、CTR、GCM 这么几个但它们的差别非常大。ECB电子密码本模式是最好理解也最不应该用的模式每组明文独立加密同样的明文组永远得到同样的密文组。这会产生模式泄漏比如一张头像图片的密文仍然能看到原图的轮廓。任何正经项目都不建议 ECB。CBC密码分组链接模式是实际中最通用的选择。它把每一组明文与前一组密文做异或后再加密所以同样的明文只要每组之前的链接过程不同最终密文也会不同。代价就是需要一个 16 字节的 IV 作为“初始链接值”而且无法并行加密长数据。CTR计数器模式则是把 AES 变成一个流密码用一个递增计数器生成密钥流然后与明文异或得到密文。它支持随机访问可以任意定位解密某一段数据适合加密超大文件或需要流式处理的场景。代价是如果计数器重复使用了同一个 IV那加密结果会直接暴露重叠部分的明文关系——这是流密码的宿命。GCM 则是带认证的模式它除了加密还能同时计算认证标签加密和防篡改一起搞定。但需要用标准实现比如本机几乎没有靠谱的 GCM 封装而 WebCrypto 原生支持 GCM。给一张实用对照表模式需要IV是否防篡改典型场景推荐指数ECB否否演练/教学不推荐CBC是否通用数据传输优先推荐CTR是否大文件/流式处理视场景推荐GCM是是现代新项目有条件则最优实际业务中我的默认选型是 CBC因为后端几乎所有语言的标准库都支持联调最省心。如果整个技术栈是 2020 年以后新起的且运行环境确认支持 WebCrypto优先 GCM。2.3 IV 和 Padding最容易被忽略的两个翻车点IV 全称 Initialization Vector初始化向量。在 CBC 模式下IV 就是“第 0 组密文”用于让加密结果随机化。这里的坑有三个。第一IV 必须是 16 字节对应 AES 块大小少一字节都不行。很多人把123456这种短字符串当 IV 传进去运行时不报错但加密结果错乱最坑的是表面看不出问题直到后端解不开才发现。第二IV 每次加密都必须随机生成不能固定。把 IV 写死在代码里的后果是同一密钥下的同一明文永远得到同一密文密文的重复模式会成为攻击线索。正确的做法是加密时随机生成 IV然后把 IV 和密文一起传给对方。注意 IV 本身不需要保密——它就像盐一样公开了也不影响安全性但你绝不能重复使用。第三如果你在前后端联调时把 IV 写死成某个固定字符串来方便调试上线前必须改成随机方案。我接过一个救火任务对方前端把 IV 写死成0000000000000000用了一整年直到某次安全扫描才暴露。这种事在真实项目里发生得比想象中多。Padding中文叫填充解决的是一个数学问题AES 是按 16 字节一组的可你明文不见得刚好是 16 的倍数。比如hello是 5 字节差 11 字节才能凑满一组多余的字节用什么填最通用的方案是 PKCS7缺多少字节就填多少字节而且每个填充字节的值都等于缺失数量。缺 1 字节就填 1 个0x01缺 11 字节就填 11 个0x0B。解密后按最后一位的值把填充去掉完美还原。这里的经典翻车点Java 里对外接口写的往往是PKCS5Padding而 JavaScript 里叫PKCS7。很多人看到名字不一样就以为模式不匹配抓耳挠腮半天。实际上 Java 的 PKCS5Padding 在某些场景下和 PKCS7 的填充规则完全一致——尤其 AES 固定 16 字节块时PKCS5 只是名字沿用旧算法的叫法本质执行的就是 PKCS7 的规则。所以前端用 PKCS7后端用 PKCS5Padding是可以联调通的。3. 完整实操从安装到前后端互通这节我们进入正题——把整个链路跑通。我用目前社区主流的 CryptoJS 为例演示同时也提一下轻量的 aes-js 怎么选。3.1 安装与引入先装包npm install crypto-js或者如果你倾向轻量、底层控制力更强的 aes-jsnpm install aes-js两者的差异值得多说两句。CryptoJS 是一个封装非常完整的库自带 WordArray、BitArray、Base64、Hex、Utf8 等编码转换工具写业务代码非常顺手我做的多数项目都用它。aes-js 则更纯粹它只做 AES 核心运算输入输出都是 Uint8Array不管编码转换好处是包体积小、逻辑透明适合有性能洁癖或者需要精确控制字节流的人。前端页面引入 CryptoJS 时浏览器环境直接用script srchttps://cdn.example.com/crypto-js.min.js/script script // 全局出现 CryptoJS 对象 /script如果是模块化项目直接import CryptoJS from crypto-js就好。这里不赘述具体 CDN 地址因为每个项目的内网源和版本策略不同按你项目里的统一依赖管理习惯来。3.2 最小可运行示例字符串加解密闭环先来一段完整可跑的代码我们逐行拆const CryptoJS require(crypto-js); // 注意这是演示用的固定密钥/IV真实项目绝不能这样写死 const key CryptoJS.enc.Utf8.parse(0123456789abcdef); // 16字节对应AES-128 const iv CryptoJS.enc.Utf8.parse(1234567887654321); // 16字节对应CBC模式 function encryptByAES(text) { return CryptoJS.AES.encrypt(text, key, { iv: iv, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }).toString(); } function decryptByAES(ciphertext) { const bytes CryptoJS.AES.decrypt(ciphertext, key, { iv: iv, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }); return bytes.toString(CryptoJS.enc.Utf8); } const plain hello aes-js, this is a secret.; const enc encryptByAES(plain); console.log(密文:, enc); console.log(解密:, decryptByAES(enc));关键参数逐项解释key和iv都用了CryptoJS.enc.Utf8.parse()把字符串转成 WordArray。0123456789abcdef正好 16 个 ASCII 字符等于 16 字节这是 AES-128 的正确字节数。很多人直接在encrypt时传一个字符串当 keyCryptoJS 内部会做一些兼容处理但输出格式和字节数非常不透明强烈建议统一用 parse 明确转字节。mode指定 CBCpadding指定 Pkcs7这两个参数要和后端严丝合缝地对齐一个字母都不能错。encrypt返回的是一个 CipherParams 对象我调用了.toString()让它变成字符串。这里有个隐蔽的大坑CryptoJS 的.toString()默认转成 OpenSSL 兼容格式——一个加了Salted__头的 Base64 字符串。这玩意如果你直接丢给后端用自己的标准库解密大概率会炸。很多前后端联调失败的案例根子都在这里。解决办法是要明确指定序列化格式。如果你和后端约定用纯 Base64 密文就改成const encrypted CryptoJS.AES.encrypt(text, key, options); const ciphertextBase64 CryptoJS.enc.Base64.stringify(encrypted.ciphertext); // 这样拿到的就是不带Saltted__头的纯密文如果约定用 Hex就换成CryptoJS.enc.Hex.stringify(encrypted.ciphertext)。解密时也有对应操作。CryptoJS.AES.decrypt接收的第一个参数可以是字符串但这个字符串的格式必须和加密时的输出格式对应上。你要是把不带Salted__头的纯 Base64 直接塞进 decrypt它用 OpenSSL 格式解析就会出错。所以最稳妥的写法是——解密时先明确把密文转成CipherParams对象再喂给解密函数。比如function decryptByAES(ciphertextBase64) { const cipherParams CryptoJS.lib.CipherParams.create({ ciphertext: CryptoJS.enc.Base64.parse(ciphertextBase64) }); const bytes CryptoJS.AES.decrypt(cipherParams, key, { iv: iv, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }); return bytes.toString(CryptoJS.enc.Utf8); }这套写法看起来啰嗦但它把“密文格式”这个变量完全钉死了——无论谁给你传什么格式都按约定好的 Base64 去解析。我在项目里遇到过好多次同事把老代码里的.toString()结果拿到新函数里解密报错Malformed UTF-8 data一查就是格式不匹配。这个写法能根治。3.3 进阶JSON 数据脱敏与本地缓存加密字符串加解密只是热身,实际业务里我们更多要处理对象数据。比如要把一个用户信息对象加密后存到 localStorage解密后还原成对象function getRandomIv() { // 16字节随机IV每次加密都不同 const words CryptoJS.lib.WordArray.random(16); return words; } function encryptObject(obj) { const iv getRandomIv(); const json JSON.stringify(obj); const encrypted CryptoJS.AES.encrypt(json, key, { iv: iv, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }); // 把iv和密文拼在一起方便解密时取出 return { iv: CryptoJS.enc.Base64.stringify(iv), data: CryptoJS.enc.Base64.stringify(encrypted.ciphertext) }; } function decryptObject(payload) { const iv CryptoJS.enc.Base64.parse(payload.iv); const cipherParams CryptoJS.lib.CipherParams.create({ ciphertext: CryptoJS.enc.Base64.parse(payload.data) }); const bytes CryptoJS.AES.decrypt(cipherParams, key, { iv: iv, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }); const json bytes.toString(CryptoJS.enc.Utf8); return JSON.parse(json); } // 使用 const userInfo { name: 某开发者, phone: 13800000000, level: 2 }; const safe encryptObject(userInfo); localStorage.setItem(user_profile, JSON.stringify(safe)); // 读取 const stored JSON.parse(localStorage.getItem(user_profile)); const info decryptObject(stored); console.log(info.name);这段代码用了随机 IV并把 IV 和密文一起存起来。这个模式一定要记牢IV 随机生成但随密文一起传递。解密时没有 IV 就解不出有了 IV 才能完整还原。本地存储时 IV 明放没关系它不泄露任何明文信息。另外补充一个性能建议不要把所有 localStorage 数据都加密。有些高频读写的数据项比如主题色、折叠状态加密后每次读都要做一次 AES 运算反而拖慢页面。我给同事的建议是只加密真正敏感的内容比如 token、用户画像、通讯录快照其他体验类数据保持明文即可。加密是手段不是装饰别为了“看起来安全”把性能毁了。3.4 与后端联调的完整流程前端加密最终要落地的关键动作是和后端把“字节层面的约定”全部对齐。我整理了个对照表按这个表逐项核对联调基本一次过约定项前端行为后端行为密钥16字节UTF8字符串与前端同一字符串转16字节密钥编码Utf8.parsegetBytes(UTF-8)模式CBCCBC填充Pkcs7PKCS5Padding实为同规则IV策略随机生成附在密文前从请求中取前16字节作为IV密文编码纯Base64不带密文头Base64解码后直接AES解密结果编码Utf8字符串/JSON字符串与前端保持一致后端伪代码示例这里用 Java 风格示意具体语言同理// 请求体里 data base64(iv ciphertext) byte[] body Base64.decode(req.get(data)); byte[] iv Arrays.copyOfRange(body, 0, 16); byte[] ciphertext Arrays.copyOfRange(body, 16, body.length); Cipher cipher Cipher.getInstance(AES/CBC/PKCS5Padding); SecretKeySpec keySpec new SecretKeySpec(AES_KEY.getBytes(UTF-8), AES); cipher.init(Cipher.DECRYPT_MODE, keySpec, new IvParameterSpec(iv)); byte[] plain cipher.doFinal(ciphertext); String json new String(plain, UTF-8);我在联调时踩过的最典型的坑就是前端把Salted__的 OpenSSL 格式密文发给后端后端 Java 直接按标准格式解抛BadPaddingException。排查了两天最后把密文格式改纯 Base64 就通了。所以强烈建议前端加密输出统一用encrypted.ciphertext对应的 Base64/Hex而不是默认的.toString()。4. 让“高级”名副其实密钥管理与防篡改设计标题敢叫“高级加密”到这个程度才算开始高级。前面的代码能跑通只是基础真正的安全水平取决于密钥怎么管理、数据怎么防篡改。这一节全是实战里总结出来的硬骨头。4.1 密钥从哪来别把钥匙放在保险箱旁边前端代码本身就是公开的你把 AES 密钥硬编码在 JS 里等于把保险箱打开把钥匙贴在箱门旁边。攻击者只要用浏览器开发者工具看一眼源码你的加密就形同虚设。所以密钥管理是前端加密的第一条命。工业界最常用也最务实的方案是动态下发密钥。具体流程是这样的用户登录成功后后端生成一个随机会话密钥AES-128 密钥用 HTTPS 安全地传给前端前端把它保存在内存变量里不要存 localStorage存了又会裸奔后续所有加解密都用这个会话密钥会话过期或退出登录密钥随之销毁。这样即使有人翻源码看到的也只有“从接口取密钥”的逻辑拿不到密钥本身。更进阶一点的方案叫混合加密前端随机生成 AES 密钥用后端提供的 RSA 公钥把这个 AES 密钥加密后传给后端后端用 RSA 私钥解密拿到 AES 密钥之后的业务数据都用 AES 密钥加解密。RSA 加密慢但只加密一个密钥没问题AES 加密快负责海量业务数据。这套方案的好处是 AES 密钥不用经过传输链路下发而是由前端生成、后端解密获取杜绝了“下发途中被截获密钥”的可能。再强调一次登录接口本身必须走 HTTPS因为密钥传输的通道如果不安全整个加密体系就没意义了。前端加密是纵深防御的一层不是替代 HTTPS 的遮羞布。4.2 加密不等于防篡改把 HMAC 加上去有一个概念经常被混淆加密解决的是机密性问题也就是“别人看不懂”而完整性校验解决的是另一个问题——“别人有没有改过我的数据”。AES-CBC 模式下攻击者即使不知道密钥也可以通过翻转某些密文位来影响解密后的明文这叫位翻转攻击。所以如果你的场景是接口参数防篡改光加密不够还需要加消息认证码。最务实的做法是 HMAC基于哈希的消息认证码。用一个只有前后端共享的密钥对明文或密文计算 HMAC 值附在请求里一起发送接收方自己也算一遍比对一致才接受。只要攻击者拿不到 HMAC 密钥就无法伪造合法数据。代码示例const hmacKey CryptoJS.enc.Utf8.parse(another-secret-key); // 对明文计算HMAC const sign CryptoJS.HmacSHA256(jsonStr, hmacKey).toString(CryptoJS.enc.Hex); // 请求参数data密文sign签名注意 HMAC 密钥和 AES 密钥要用两个不同的密钥。如果同一个密钥既做加密又做认证在某些场景下会存在安全问题实践中分开管理成本极低收益明确。如果项目已经用了 WebCrypto 的 GCM 模式那 GCM 自带认证标签等于加密和防篡改一起完成了不需要单独算 HMAC。4.3 安全红线清单这些年做安全升级我给自己列过一张红线清单每次 Code Review 看到这些苗头都会直接打回。分享出来你可以拿它当自查表前端代码里硬编码 AES 密钥或 IV——直接打死密钥必须动态获取或协商生成。所有加密都用同一个固定 IV——至少要在每个会话或每条记录里随机生成。使用 ECB 模式加密业务数据——明文模式会泄漏业务数据一律 CBC 或更高。明文和密文一起打在日志里——日志系统被拖库后密文的保密性全废。用前端加密替代 HTTPS——两者是不同层面的安全必须同时存在。密钥存放在 localStorage 或任何可持久化存储里——密钥应该活在内存不该落盘。这些红线不是理论推导每条我都见过真实翻车现场。最讽刺的是第 5 条有团队觉得“都加密了上不上 HTTPS 无所谓”结果加密的数据包还是在链路上被完整截获加密算法再强也没能挡住中间人把改过的密文转发给后端。传输层安全必须靠 HTTPS这个真没得商量。5. 高频问题与排障实录这一节算是硬核经验合集。我整理了近两年在做加密联调、技术咨询时碰到的高频问题每条都标注了根因和解法。5.1 后端 Java/C#/Go 解不开前端数据这是最高频的问题没有之一。表象是前端加密明明成功后端一解密就抛异常或出来乱码。根因百分之九十都在下面这五个点可能原因检查方式解决方案密钥编码不一致前端用Utf8.parse后端用getBytes(GBK)或指定字符集不同统一UTF-8密文带了Salted__头检查Base64前几位是否是U2FsdGVkX1用enc.Base64.stringify(ciphertext)拿纯密文模式不一致前端CBC后端默认ECB或相反显式指定CBC并确认Padding不匹配前端Pkcs7后端NoPadding或PKCS1统一为PKCS7/PKCS5PaddingIV没有传给后端前端随机IV后端却写死把IV编入请求体并让后端取用第一个和第三个是我遇到最多的。有一个项目前端工程师和后端工程师分别照着两份完全不同的教程写加密逻辑前端用 ECB 模式后端用 CBC 模式而且两边都不知道对方用了什么模式。联调了两周没通最后拉了个对子逐项对才发现模式不一样。所以我一直建议前后端联调前要先拉一个“加密参数确认单”把密钥、IV 策略、模式、Padding、编码格式列成表格邮件或文档形式确认好再动手写代码。磨刀不误砍柴工。5.2 报错“Malformed UTF-8 data”或“Unexpected token”怎么办这类报错在解密时才常见。很多人的第一反应是“密钥错了”但其实往往是密文格式处理不对。CryptoJS 的AES.decrypt(ciphertext, key)里传入的ciphertext如果是字符串会被默认当作 OpenSSL 格式带Salted__头的 Base64去解析。如果你的密文是纯 Base64 或 Hex解析就会失败。正确做法就是我前面写过的用CipherParams.create先把密文转成明确的二进制对象再喂给解密函数。这样绕开了 CryptoJS 默认格式的陷阱。还有一种情况是搞混了 Base64 和 Hex。有人加密时用CryptoJS.enc.Hex.stringify()输出十六进制字符串解密时却用CryptoJS.enc.Base64.parse()去解析——这就变成了“用 A 编码再用 B 解码”结果必然乱码。记住parse 和 stringify 是一对什么格式出去的就什么格式回来。5.3 解密结果乱码且长度不对这个问题的根源几乎都是密钥或 IV 的字节数不对。AES-128 要求密钥恰好 16 字节。如果你在Utf8.parse时传入的是一个 15 字节或 18 字节的字符串CryptoJS 不会报错——它只把能用的部分拿来用剩下的直接忽略导致前后端实际用的密钥根本不是同一把。这种 bug 极其隐蔽因为明文短时可能恰好能解出来一旦明文变长结果就彻底乱了。更离谱的是有人直接在encrypt函数里传字符串当密钥。CryptoJS 对字符串密钥有一套内部处理逻辑它会把密码通过哈希派生真实密钥如果你前端这么写而后端没用同样的派生逻辑神仙来了也解不开。稳妥的做法是密钥和 IV 都明确用parse转字节并通过代码断言来防呆const key CryptoJS.enc.Utf8.parse(0123456789abcdef); if (key.sigBytes ! 16) { throw new Error(AES-128密钥必须是16字节当前是 key.sigBytes); }这样万一有人后来改动了密钥字符串联调时能第一时间炸出问题而不是在线上环境里解出一堆乱码再排查。5.4 性能与包体积的真实体感最后说点实践层面容易忽略的性能和包体积。CryptoJS 完整包编译后大约 100KB 左右对现代前端项目来说不算大但如果你只用了 AES 一家的功能可以把引入方式改成按需加载避免把所有算法打进主包。例如import AES from crypto-js/aes; import modeCBC from crypto-js/mode-cbc; import padPkcs7 from crypto-js/pad-pkcs7; import encUtf8 from crypto-js/enc-utf8;这样最终打包体积能明显降下来实测能从 100KB 级别降到 40KB 上下。至于性能我实测过在主流桌面浏览器上用 AES-128-CBC 加密一个 1MB 的字符串耗时大概在几十到一百毫秒这个量级几乎无感但在低端手机上反复调用加密会带来可感知的卡顿尤其是加密大 JSON 或高频轮询的场景。优化办法就三条能不加密就不加密、把加密内容控制在最小范围、V8 引擎解析慢就缓存密文避免重复加密。aes-js的包体积会更小一些因为它不做编码转换纯核心算法约几十KB。但代价是你得自己手工处理字节流、补零、拼接 IV 等细节。如果项目对包体积有洁癖且你有信心驾驭底层字节操作aes-js值得考虑否则我建议用 CryptoJS 或类似封装库省心优先。再分享一个我个人的排障心法遇到加密解密问题第一件事不是看代码而是先拉一张“参数对照表”贴在会议室白板上——密钥值、密钥编码、模式、Padding、IV 策略、密文格式逐项跟对方核对。所有加密联调的疑难杂症百分之九十九都能在这张表里找到凶手。我后来每个加密项目开工前都会先发一版这样的表格给后端同事确认签字后再写代码。这个习惯替我节省了无数加班时间真的可以试试。