HTTPS是传输层安全基石，但无法防止日志泄露、控制台误打或恶意脚本窃取；AES加密可提升应用层防护，关键在密钥长度、IV与填充方案前后端严格对齐。
前端用 layui 做表单提交时，直接传明文（比如密码、手机号）等于把钥匙挂在门把手上——HTTPS 能防中间人，但防不了日志泄露、控制台误打、或被恶意脚本 hook $.post。AES 加密不是银弹，但它能快速抬高批量抓取和调试窥探的成本。关键不在“会不会用”，而在“参数对不对、编码是否一致、前后端是否咬合”。下面直奔实操。
crypto-js 的 AES.CBC 模式必须配齐 key、iv 和 padding
layui 本身不提供加解密能力，得靠 crypto-js。很多人复制代码后解密失败，90% 出在三件事没对齐：密钥长度、IV 解析方式、填充方案。
-
CryptoJS.AES.encrypt默认用Pkcs7填充，但有些后端（如老版 .NETRijndaelManaged）默认是Zeros，会导致解密后末尾多出乱码字节 - key 和 iv 必须是
CryptoJS.enc.Utf8.parse或CryptoJS.enc.Latin1.parse后的 WordArray，不能直接传字符串——否则实际用的是字符串 UTF-8 字节长度，而 Java/Python 后端按字节数理解，极易错位 - AES-128 要求 key 长度为 16 字节（不是 16 个字符），中文或 emoji 会占多个字节，建议统一用英文+数字组合，例如
"a1b2c3d4e5f6g7h8"
layui 表单提交前手动加密字段，别动 layui.form 自动序列化
layui 的 form.on('submit') 事件里，data 是自动收集的键值对对象。你不能直接对整个 data 对象加密，而要逐字段处理——尤其是密码、身份证、手机号这类敏感字段。
示例（配合 crypto-js v4.2+）：
form.on('submit(login)', function(data) {
var pwd = data.field.password;
var key = CryptoJS.enc.Utf8.parse('a1b2c3d4e5f6g7h8');
var iv = CryptoJS.enc.Utf8.parse('i9j0k1l2m3n4o5p6');
var encrypted = CryptoJS.AES.encrypt(
pwd, key,
{ iv: iv, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }
).toString();
// 替换原始字段，再提交
data.field.password = encrypted;
$.post('/api/login', data.field, function(res) {
// 处理响应
});
return false;
});
后端解密失败？先比对 base64 编码和 IV 传递方式
crypto-js 输出的是 base64 字符串，但它的 base64 编码规则和标准 OpenSSL 兼容。问题常出在后端没做正确拆分：
HISUI 前端框架基础开发指南。HISUI 是基于 easyui 二次开发的 jQuery UI 组件库，专为医疗信息系统设计。当涉及 HISUI 组件开发、jQuery easyui 表格/表单/布局/窗口、医疗系统前端页面编写时使用此 skill。 涵盖 40 个组件的官方文档参考，支持声明式与编程式两种初始化方式，提供 $cm/$m 数据访问方法。
- 前端只传密文（如
"U2FsdGVkX1+..."），后端需自己生成 IV —— 错！crypto-js 的encrypt().toString()实际是salt + iv + ciphertext的 base64 封装，无法分离；必须前端显式传 iv（base64 或 hex） - 推荐做法：前端把 iv 也转成 base64，和密文一起发，例如
{ "password": "...", "iv": "aTlqMGsxbDJtM240bzVwNg==" } - PHP 用
openssl_decrypt时，$iv必须是 raw binary，不能是 base64 字符串，要用base64_decode($iv)先转 - Java 若用
javax.crypto.Cipher，IvParameterSpec构造时传入的 byte[] 必须与前端CryptoJS.enc.Utf8.parse(iv).toString(CryptoJS.enc.Base64)解码后一致
别在前端硬编码密钥，哪怕它只是临时的
有人把 key 写死在 JS 里还加注释“测试密钥，请勿上线”——上线那天就忘了删。更糟的是，有人把 key 拼在 URL 里请求后端获取，结果被 CDN 缓存或 referer 泄露。
可行底线方案：
- 登录页首次加载时，由后端在 HTML 模板中注入一个单次有效的 key（如 JWT 签发的短期密钥），前端用完即弃
- 用环境变量 + 构建时替换（如 Webpack
DefinePlugin），确保 dev 和 prod 密钥不同 - 完全规避前端密钥管理：改用 RSA 公钥加密 AES 密钥（即混合加密），前端用后端提供的公钥加密一次随机生成的 AES key，再用该 AES key 加密业务数据——这需要后端配合提供公钥接口
最易被忽略的一点：crypto-js 的 CBC 模式下，相同明文 + 相同 key + 相同 iv 每次加密结果都一样。攻击者可据此做重放或模式分析。生产环境务必每次请求生成新 iv，并和服务端约定传输方式。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
