localstorage持久存储且同源共享，适合用户偏好；sessionstorage仅限当前会话，适合临时数据；两者均遵循同源策略，api相同但作用域与生命周期不同。
Web Storage 的持久化能力与容量限制，直接决定了它适合存什么、不适合存什么。关键不是“能不能存”，而是“该不该长期存”和“有没有空间存”。
localStorage 是真正的持久化存储
数据写入 localStorage 后，只要用户不主动清除（比如清空浏览器缓存、手动调用 clear() 或删除特定项），它就会一直保留在设备上——关机、重启、重装浏览器（除非同步了配置）都不影响。这不是“默认保留”，而是设计上的持久承诺。
- 适用场景：用户主题偏好、登录态 token（需配合 HttpOnly Cookie 更安全）、离线缓存的静态资源标识、长期有效的配置开关
- 注意点：它不自动过期，也不随页面跳转丢失，但同源策略严格——https://a.com 和 https://b.com 完全隔离，甚至 http://example.com 和 https://example.com 也互不可见
- 常见误区：把它当“安全保险箱”存密码或敏感凭证；实际上 localStorage 数据可被任意前端脚本读取，XSS 攻击下极易泄露
sessionStorage 是会话级临时存储
它的生命周期绑定到单个浏览器标签页（tab）。页面刷新、路由切换不影响数据；但一旦关闭该标签页，所有 sessionStorage 数据立即销毁。新开一个同域名标签页，哪怕 URL 完全一样，也是全新的 sessionStorage 空间。
- 适用场景：多步骤表单的中间状态、临时筛选条件、当前页的 UI 展开状态、一次性操作凭证（如短信验证码提交前的临时缓存）
- 注意点：它不跨 tab 共享，也不能用于“记住我”类需求；即使同一域名下两个 tab 同时打开，它们的 sessionStorage 互不干扰
- 典型误用：用它保存用户登录信息试图实现“保持登录”，结果关掉 tab 就登出——这其实是正确行为，不是 bug
容量限制实际约 5–10MB，且按源独立计算
主流浏览器（Chrome、Firefox、Edge）对每个源（origin）的 localStorage 和 sessionStorage 分别分配约 5MB 存储空间；Safari 在某些模式下可达 10MB，但 iOS 上可能更保守。这个限额是硬性限制，超出时 setItem() 会抛出 QuotaExceededError 异常。
- 字符串才是唯一合法值：所有存入的数据都会被强制转为字符串，对象必须先 JSON.stringify()，读取时再 JSON.parse()；否则存进去的是 [object Object]
- 空间占用容易被低估：Base64 图片、未压缩的 JSON 日志、大量历史记录都很快吃满 5MB；建议定期清理过期 key，或用 length 和 key(i) 主动监控使用量
- 不要和 cookie 混淆：cookie 仅 4KB 且每次请求都发给服务器，Web Storage 完全本地、不参与网络传输，这才是它容量更大的根本原因
storage 事件帮你响应跨页面变更
当同一个源下的其他 tab 或 window 修改了 localStorage，当前页面能通过监听 storage 事件获知变化——但注意：触发事件的页面自身不会收到该事件，只通知其他监听者。
- 典型用途：多窗口协同时同步主题色、登出广播（一个 tab 登出，其他 tab 自动跳转登录页）、实时配置更新
- 事件参数含 key、oldValue、newValue 和 url，可用于精准判断哪项变了、从什么值变成什么值
- sessionStorage 不触发 storage 事件，因为它天然不跨页面，无需通知机制
