localStorage vs sessionStorage
localStorage vs sessionStorage
1. 它们是什么？
二者都属于Web Storage API：
- 都是浏览器提供的键值对存储（Key-Value）。
- 只支持存字符串（对象需要
JSON.stringify/parse）。 - 同源策略限制：同协议 + 同域名 + 同端口才能互相访问。
2. 核心差异对比（表格）
| 维度 | localStorage | sessionStorage |
|---|---|---|
| 生命周期 | 长期：除非手动清除（代码删除/用户清理浏览器数据） | 会话级：关闭当前标签页/窗口即清除 |
| 刷新页面 | 保留 | 保留 |
| 关闭标签页 | 保留 | 清除 |
| 新开同域标签页 | 可共享（同源下可读同一份） | 不共享（每个标签页独立） |
| 容量（大致） | 通常 5MB 左右（各浏览器实现有差异） | 通常 5MB 左右（各浏览器实现有差异） |
| API | setItem/getItem/removeItem/clear | 同localStorage |
| 典型用途 | 记住登录态、主题设置、长期偏好 | 临时表单草稿、一次性流程状态、单标签页会话缓存 |
3. 代码层面的共同点
3.1 写入与读取
// 写入localStorage.setItem('token','xxx')sessionStorage.setItem('token','xxx')// 读取constt1=localStorage.getItem('token')constt2=sessionStorage.getItem('token')// 删除localStorage.removeItem('token')sessionStorage.removeItem('token')3.2 存对象（需要序列化）
constuser={id:1,name:'Alice'}localStorage.setItem('user',JSON.stringify(user))constparsed=JSON.parse(localStorage.getItem('user')||'null')4. “点击刷新仍保持登录态”的关键点
- 刷新会导致 JS 内存状态（如 Pinia/Vuex/组件 state）全部丢失。
- 只要 token 存在于持久化存储中（
localStorage或sessionStorage），应用重新加载后仍能读到 token，并在请求拦截器里带上。
区别在于：
- 用
localStorage：关闭浏览器/标签页后再次打开仍可保持登录（除非 token 过期或被清理）。 - 用
sessionStorage：关闭当前标签页就需要重新登录。
5. 登录态场景怎么选？
5.1 管理后台常见选择：localStorage
原因：
- 管理后台用户通常希望“记住登录态”，避免频繁登录。
- 支持多标签页共享同一登录态（同源下）。
方法：
- 登录成功后
setToken(token)写入localStorage request.js每次请求前getToken()读出并写入请求头
5.2 何时更适合sessionStorage
- 需要更“严格”的会话：
- 关闭标签页就自动退出
- 不希望 token 在磁盘上长期保留
- 单标签页流程状态：
- 多步骤表单
- 临时筛选条件
- 一次性引导流程
6. 安全性与风险（重要）
6.1 XSS 风险：二者都一样
localStorage与sessionStorage都能被页面 JS 读取。- 一旦站点存在 XSS 漏洞，攻击脚本可以直接读走 token。
因此：
- 防 XSS（输入输出转义、CSP、依赖治理）比“选 local 还是 session”更关键。
6.2 更安全的替代：HttpOnly Cookie（思路）
若你想降低“JS 可读 token”的风险，可考虑把 token 放在：
- 服务端下发的
HttpOnlyCookie（JS 不可读）
但这会带来：
- CSRF 防护需求（SameSite、CSRF Token 等）
- 与后端鉴权方式的配套改造
7. 实用选型建议
- 想要“关闭浏览器/标签页后仍记住我”：选
localStorage（或更安全的 Cookie 方案）。 - 想要“关闭标签页就退出”：选
sessionStorage。 - 临时状态（一次流程、草稿）：优先
sessionStorage。 - 不管选哪个：都需要重视 XSS 风险；登录态过期时要做一致的清理与跳转。