敏感信息绝不可存入 localstorage，因其明文存储、无访问隔离、无自动过期，易遭 xss、恶意扩展或第三方脚本窃取；应改用 httponly cookie 存凭证，前端仅缓存非敏感数据。
别用 localStorage 存敏感数据——这不是建议，而是安全底线。它本质是明文、无隔离、无过期的前端存储，任何能执行 JS 的上下文（XSS、恶意扩展、第三方脚本）都能一键读取、篡改或外传。
为什么风险远比想象中严重
localStorage 不是“稍微不安全”，而是设计上就不该碰敏感字段：
- XSS 是直接提款机：只要页面存在一个未过滤的输入点，攻击者注入<script>localStorage.getItem('token')</script>就能把凭证发到自己的服务器。
- 同源即全员可读：你引入的统计 SDK、广告组件、UI 库，只要同源，就能访问全部 localStorage 内容，你无法审计每行第三方代码。
- 浏览器里裸奔：用户打开 DevTools → Application → LocalStorage，手机号、身份证掩码、甚至 base64 编码的私钥，全都清晰可见。
- 没有生命周期管理：存进去就永远在，除非手动删；公共电脑上一次登录没退出，下一个人打开网页就能复用会话。
真正可用的安全替代方案
不是“怎么加密 localStorage”，而是“根本别让它接触敏感数据”：
-
身份凭证走 HttpOnly Cookie：后端设置
Set-Cookie: token=xxx; HttpOnly; Secure; SameSite=Strict，前端 JS 完全不可读，从源头阻断 XSS 窃取。 - 敏感字段按需接口返回：用户昵称、头像可以缓存；但手机号、余额、实名信息，每次需要时调接口获取，且服务端做权限校验，不落本地。
- 临时敏感操作用 sessionStorage：比如支付确认页的订单摘要，关掉标签页自动清空，比 localStorage 少一层长期暴露风险。
-
密钥类数据优先 Web Crypto：私钥导入时设
extractable: false，只允许 sign/decrypt，绝不以字符串形式落地；必须持久化时，用主密钥加密后存 IndexedDB，而非 localStorage。
哪些数据其实可以放心存
localStorage 并非一无是处，关键在“非敏感”和“低风险”：
- 用户界面偏好：主题色、字体大小、折叠菜单状态；
- 静态资源缓存标识：如已加载的图标版本号、离线文案哈希值；
- 匿名行为标记：是否看过某弹窗、最近搜索关键词（不含用户 ID）；
- 表单草稿（不含证件号/银行卡）：比如未提交的地址、备注文字。
安全不是加一层加密壳，而是把数据放在它该在的地方。敏感数据天生属于后端管辖范围，前端只负责展示和交互——守住这个边界，比任何前端加密都管用。
