不建议在 localStorage 中存储临时加密密钥，因其无访问控制、易受 XSS 攻击、无法加密存储、生命周期失控且同源脚本均可读取；推荐使用内存变量、Web Crypto API（extractable=false）或服务端托管。
不建议在 localStorage 中存储临时加密密钥，即使它是算法生成的、仅用于前端短期使用的密钥。
为什么 localStorage 不适合存加密密钥
localStorage 是纯前端、同步、无访问控制的持久化存储机制，所有 JavaScript（包括第三方脚本、浏览器扩展、XSS 注入代码）均可读写。一旦页面存在任意 XSS 漏洞，攻击者可在用户会话中直接提取密钥，彻底破坏加密逻辑的安全前提。
- 密钥未加密：浏览器不提供对
localStorage的自动加密保护；你无法安全地“加密后再存进 localStorage”——因为加密密钥本身又得存在某处，陷入循环依赖。 - 生命周期失控：
localStorage数据默认永不过期，关闭标签页或浏览器后仍存在，与“临时”属性矛盾。 - 同源策略≠安全隔离：同源下任意脚本（广告 SDK、埋点工具、被污染的 npm 包）都能调用
localStorage.getItem('key')窃取。
更合理的替代方案
根据密钥用途选择合适载体，优先保障机密性与作用域最小化：
-
内存变量（推荐用于真正临时密钥）：在需要时生成（如 AES-GCM 密钥），全程只存在于 JS 变量中，使用后立即设为
null或让其自然脱离作用域。不序列化、不跨函数传递引用，避免意外泄露。 -
Web Crypto API + 内存绑定：用
crypto.subtle.generateKey()创建密钥对象，其extractable设为false，则无法导出为字符串，只能通过subtle.encrypt()等接口内部使用，天然防读取。 - 服务端托管（需网络交互）：密钥由后端生成并返回短期有效的加密令牌（如 JWT 加密 payload），前端仅持令牌，解密/验签逻辑交由服务端完成，密钥永不落地前端。
如果必须前端临时存储（极少数场景）
例如离线加密待同步的本地草稿，且可接受一定风险，则需严格约束：
立即学习“前端免费学习笔记（深入）”；
- 密钥生成后立即派生并销毁原始密钥（如用 HKDF 从主密钥派生会话密钥，主密钥不保存）；
- 存储前用用户当前登录态（如 session ID 的哈希片段）做简单混淆（非加密），增加批量提取难度；
- 设置明确过期时间，每次读取前校验
Date.now() < expiryTimestamp，过期即清除； - 避免使用固定 key 名（如
'temp_key'），动态构造 key（如拼接时间戳+随机盐）提升探测成本。
本质上，密钥不是数据，而是访问凭证。把它放进 localStorage，就像把家门钥匙粘在防盗门玻璃上——看起来还在自己手里，实则谁路过都能拿走。
