应使用 Web Crypto API 的 AES-GCM 加密敏感数据后再存入 localStorage/sessionStorage；密钥须 256 位，IV 随机唯一 12 字节；推荐 PBKDF2 派生密钥或临时会话密钥；加密结果需 Base64 编码并结构化存储。
可以用 localStorage 或 sessionStorage 存数据，但它们本身不加密；要真正保护敏感信息，得先用 Web Crypto API 加密，再存入 Storage。关键不是“能不能”，而是“怎么安全地做”——重点在密钥管理、算法选择和防止常见陷阱。
选对加密算法和模式
推荐使用 AES-GCM（AesGcm），它同时提供机密性和完整性验证，避免手动拼接 IV 和认证标签的错误。
- 密钥长度必须为 256 位（32 字节），用
importKey导入时指定length: 256 - IV（初始化向量）必须随机生成且每次唯一，长度固定为 12 字节（GCM 推荐值），不能复用
- 不要用 ECB、CBC 等需手动处理填充和 MAC 的模式，GCM 内置认证，更难出错
安全生成和保管密钥
浏览器里无法长期安全保存密码或主密钥，所以实际方案分两类：
-
用户口令派生密钥（PBKDF2）：用
deriveKey+PBKDF2，盐值（salt）必须随机且单独存储（比如和密文一起存），迭代次数 ≥ 100,000 -
临时会话密钥（适合短期敏感数据）：用
generateKey创建一次性密钥，通过内存变量传递，绝不存入 Storage —— 密钥本身不落地 - 避免把密钥硬编码、存在 localStorage、或从 URL/cookie 读取
加密后序列化与存储
加密结果是 ArrayBuffer，不能直接塞进 localStorage.setItem()，必须转成可存储格式：
立即学习“前端免费学习笔记（深入）”；
- 推荐用 Base64 编码：用
btoa(String.fromCharCode(...new Uint8Array(buffer)))或更健壮的ArrayBuffer → base64url（去掉+和/，替换=） - 把 IV、密文、可选的 salt 都打包成一个对象，再
JSON.stringify存入：
{ iv: "base64...", data: "base64...", salt: "base64..." } - 解密时反向操作：JSON 解析 → Base64 解码 → 构造
Uint8Array→ 传给decrypt()
注意权限与兼容性边界
Web Crypto API 要求页面运行在安全上下文（https:// 或 localhost），HTTP 页面会静默失败；且部分旧版 Safari 对 GCM 支持不稳定。
- 调用前检查支持：
if (window.crypto && crypto.subtle) - 异步操作必须用
await或.then()，所有加密/解密方法都返回 Promise - 不要在
localStorage中存原始口令、JWT token、API key 等——即使加密了，若密钥管理不当，仍可能被提取复用
