API 用法、容量、生命周期、适用场景

Web Storage 提供了两套几乎相同的 API——localStorage 和 sessionStorage，它们都是挂载在 window 对象上的全局属性。两者用法完全一致，核心区别仅在于数据的生命周期和共享范围。

API 用法

// ------ 写入数据 ------
// 推荐：使用 setItem
localStorage.setItem('theme', 'dark');
sessionStorage.setItem('tempId', 'abc123');

// 也可以直接像操作对象一样赋值（不推荐，因为 key 可能和内置属性冲突）
localStorage.username = '张三';

// ------ 读取数据 ------
const theme = localStorage.getItem('theme');   // 'dark'
const tempId = sessionStorage.getItem('tempId'); // 'abc123'

// 读取不存在的 key 会返回 null，而非 undefined
const missing = localStorage.getItem('nonexistent'); // null

// ------ 删除数据 ------
localStorage.removeItem('theme');   // 删除单个 key
sessionStorage.clear();            // 清空当前源下所有数据

// ------ 遍历数据 ------
for (let i = 0; i < localStorage.length; i++) {
  const key = localStorage.key(i);   // 获取第 i 个键名
  const value = localStorage.getItem(key);
  console.log(key, value);
}

几个关键点：

存储的值必须是字符串。如果存储对象或数组，需要用 JSON.stringify() 转换，取出时再用 JSON.parse() 还原。
setItem 会覆盖已存在的同名 key。
clear() 会清空同源下所有数据，使用时务必谨慎。

容量

标准规范建议每个源（协议+域名+端口）的存储上限为 5MB。
不同浏览器的实际限制略有浮动，移动端浏览器可能更小（部分低端设备只有 2~3MB）。
超出容量时，setItem 会抛出 QuotaExceededError 异常，所以在写入大量数据时建议用 try...catch 包裹。
与 Cookie 的 4KB 限制相比，5MB 已经足够存储大部分用户配置、缓存数据甚至小型离线资源。

生命周期

| 特性 | localStorage | sessionStorage |
|------|-------------|----------------|
| 数据存活时间 | 永久，除非手动删除或用户清除浏览器数据 | 仅当前标签页会话期间有效 |
| 关闭标签页 | 数据仍在 | 数据立即清除 |
| 刷新页面 | 数据仍在 | 数据仍在 |
| 复制标签页 | 数据共享 | 浏览器行为不一致：Chrome 会复制一份，Firefox 不会 |
| 恢复关闭的标签页 | 数据仍在 | 数据通常保留（取决于浏览器实现） |
| 跨标签页共享 | 同源的所有标签页共享 | 仅限同一标签页，不同标签页独立 |

sessionStorage 的“会话”定义：只要浏览器标签页没有关闭，即使重新加载或跳转到同源页面，数据都会保留。但一旦关闭标签页（不是浏览器），sessionStorage 中的数据就会被永久清除。这使它特别适合存储仅在单次使用流程（例如多步骤表单、临时搜索条件）中需要的临时数据。

适用场景

localStorage 常用场景

用户偏好设置：主题（暗色/亮色）、语言、字体大小。
登录标记：存储用户的登录凭证或 token（注意安全风险，敏感信息应加密或改用 httpOnly Cookie）。
表单草稿自动保存：防止用户意外关闭页面后丢失已填写内容。
本地缓存：对不常变动的接口数据进行前端缓存，减少重复请求。
产品引导状态：标记用户是否已经看过引导页，避免重复弹出。

sessionStorage 常用场景

多步骤表单的步骤间数据传递（如注册分步填写，在同标签页的页面跳转中保持数据）。
页面间临时共享数据（比如列表页跳转详情页时需要携带复杂参数，而 URL 不适合或不够安全）。
避免重复提交：在表单提交期间设置标记，防止用户多次点击。
敏感操作的临时令牌（比放在 URL 参数中更安全，关闭页面即失效）。

什么时候不该用 Web Storage？

不要存储大量结构化数据（考虑 IndexedDB）。
不要存储需要跨域共享的数据（受同源策略限制）。
不要将敏感信息（如明文密码、信用卡号）直接存入，它们完全暴露在客户端，XSS 攻击可直接读取。
不要依赖 sessionStorage 作为业务关键数据的唯一保障，因为用户可以随时关闭标签页，数据会丢失。

掌握这两兄弟的核心差异，就能在合适的场景用对工具，既提升用户体验，也避免产生难以排查的数据错乱问题。