前端JavaScript加密不等于安全加密，因代码、密钥、逻辑完全暴露，仅能防低门槛窃取；Web Crypto API是唯一可信原生方案，但密钥须后端分发或PBKDF2派生，AES-GCM推荐用于对称加密，Base64等仅为编码非加密，敏感操作应移至后端。
前端 JavaScript 加密 ≠ 安全加密
JavaScript 在浏览器中运行，所有代码、密钥、逻辑都对用户完全可见。这意味着 localStorage 里存的密钥、crypto.subtle 里用的 importKey、甚至混淆过的 AES 函数，只要在客户端执行，就无法防止被逆向或绕过。所谓“前端加密”，实际只能做到「防低门槛窃取」或「满足协议格式要求」（比如把密码转成 base64 传给后端），而不是真正保护敏感数据。
Web Crypto API 是唯一可信赖的原生加密能力
现代浏览器（Chrome 68+、Firefox 60+、Safari 16.4+）支持 window.crypto.subtle，它提供符合标准的 AES-GCM、RSA-OAEP、HMAC、SHA-256 等算法，且密钥可标记为 extractable: false，防止被导出。但注意：密钥仍需由后端安全分发或通过密码派生（如 PBKDF2），不能硬编码在 JS 里。
- 对称加密推荐用
AES-GCM：支持加密 + 认证，避免手动拼接 IV 和 MAC - 非对称加密只用于密钥交换或签名，不要用它直接加密大量数据（性能差、有长度限制）
-
SubtleCrypto.generateKey()创建的密钥必须用exportKey()显式导出才能序列化，否则无法跨页面/会话使用
const encoder = new TextEncoder();
const data = encoder.encode("hello");
const key = await crypto.subtle.generateKey({ name: "AES-GCM" }, true, ["encrypt", "decrypt"]);
const iv = crypto.getRandomValues(new Uint8Array(12));
const encrypted = await crypto.subtle.encrypt(
{ name: "AES-GCM", iv },
key.key,
data
);
Base64、Hex、URL 编码不是加密，只是编码
很多项目误把 btoa()、Buffer.toString('hex')（Node.js）、encodeURIComponent() 当作“加密”。它们无密钥、无混淆、可逆性极强，仅用于数据格式适配（比如让二进制塞进 JSON 字段或 URL 参数），不提供任何安全性。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
btoa("admin:123")→"YWRtaW46MTIz"，用任意在线工具秒解 - 前端用
sha256对密码哈希再提交？除非配合服务端 salt + 多轮迭代（如 PBKDF2），否则彩虹表可直接破解常见密码 - 第三方库如
crypto-js默认使用弱 IV（全零）和 ECB 模式（已弃用），不配置mode和padding就用，等于没加锁
真正该做的：把加密逻辑移出前端
敏感操作——比如支付签名、文档加解密、用户私钥管理——应由后端完成。前端只负责收集输入、调用 HTTPS 接口、展示结果。若必须前端参与（如端到端加密聊天），则：
立即学习“Java免费学习笔记（深入）”；
- 密钥永不落地：用
crypto.subtle.generateKey()创建，extractable: false，内存中使用完即丢 - 密码派生必须用
PBKDF2或scrypt（Web Crypto 支持前者），迭代次数 ≥ 100,000 - 避免在
console.log()、localStorage、URL query 中暴露密文、IV、salt
最常被忽略的一点：即使用了 AES-GCM，如果 IV 重复使用，攻击者就能恢复明文——而前端用 Math.random() 生成 IV 是灾难性的。务必用 crypto.getRandomValues()。
