JavaScript无原生AES API，前端加密不安全；真需加密应使用Web Crypto API的SubtleCrypto.encrypt()，配合AES-GCM、随机IV、非导出密钥及HTTPS环境。
JavaScript 里没有原生 AES 加密 API，别直接用 CryptoJS 或 forge 做生产环境加密
浏览器端 JavaScript 无法安全保管密钥，任何前端加密都只是“防君子不防小人”。CryptoJS 等库容易让人误以为“用了 AES 就安全了”，但密钥硬编码在 JS 文件里、或从服务端明文获取，攻击者打开 DevTools 就能照抄解密逻辑。真正需要保密的数据（如用户密码、token、敏感字段）必须交由后端处理。
真要前端加密，优先用 Web Crypto API 的 SubtleCrypto.encrypt()
这是目前唯一被现代浏览器原生支持、且密钥可隔离的方案。它要求密钥通过 importKey() 导入，且不能被 JS 直接读取（key.extractable === false）。注意以下实操要点：
- 只能在
https或localhost下运行，http页面会抛出SecurityError - 推荐使用
"AES-GCM"模式（带认证），不要用已淘汰的"AES-CBC" - IV（初始化向量）必须每次随机生成，且需和密文一起传给后端，不能复用
- 密钥不能是字符串口令，必须用
deriveKey()从口令 + salt 派生，或由后端下发加密后的密钥
const encoder = new TextEncoder();
const data = encoder.encode("hello world");
// 生成随机 IV
const iv = crypto.getRandomValues(new Uint8Array(12));
// 假设已有密钥 key（类型为 CryptoKey，由 importKey 得到）
const encrypted = await crypto.subtle.encrypt(
{ name: "AES-GCM", iv },
key,
data
);
// encrypted 是 ArrayBuffer，需转成 base64 或 Uint8Array 传输
常见错误：把 Base64 当加密，或用 btoa()/atob() “假装加密”
btoa() 只是编码，不是加密。它等价于 Base64 编码，无密钥、无混淆、无安全性可言。开发者常把它和加密混用，结果日志里全是明文变体，Burp Suite 一抓就 decode 出来。
-
btoa("admin:123")→"YWRtaW46MTIz"，毫无防护作用 - 所有前端“加密”逻辑若没密钥参与、没调用
subtleCrypto，基本等于裸奔 - JWT 的 payload 默认也是 Base64Url 编码，不是加密——别误以为加了点号就是安全的
真正该做的：前端只做最小必要加密，其余全交给 HTTPS + 后端
绝大多数场景下，你不需要在前端加密数据。正确做法是：
立即学习“Java免费学习笔记（深入）”；
- 用 HTTPS 保证传输过程机密性（TLS 已解决链路加密）
- 敏感操作（如支付、改密）强制二次验证，而不是靠前端加一层“障眼法”
- 前端仅对非关键数据做轻量混淆（如埋点 ID 换 Base32，不涉及密钥）
- 密钥管理统一由后端 KMS（如 HashiCorp Vault、AWS KMS）托管，前端只申请临时加密 Token
Web Crypto 虽可用，但密钥生命周期、错误处理、降级兼容（比如 Safari 对某些 GCM 参数校验更严）都容易出错。一旦选了这条路，就得为每个浏览器版本写适配逻辑，而不是写一次就完事。
