当前位置：首页 > 文章列表 > 文章 > 前端 > Cookie、SessionStorage和LocalStorage区别解析

Cookie、SessionStorage和LocalStorage区别解析

2026-02-05 12:37:50 0浏览收藏

小伙伴们有没有觉得学习文章很有意思？有意思就对了！今天就给大家带来《Cookie、SessionStorage与LocalStorage区别详解》，以下内容将会涉及到，若是在学习中对其中部分知识点有疑问，或许看了本文就能帮到你！

该用 document.cookie 而非 localStorage 时：需服务端自动收发凭证（如 HttpOnly token）、防 XSS、兼容低版本浏览器或隐私模式；localStorage 无法自动发送至后端且易受 XSS 攻击。

Cookie、SessionStorage和LocalStorage有什么区别【教程】

什么时候该用 `document.cookie`，而不是 `localStorage`

当你需要服务端参与状态管理时，必须用 cookie。比如登录后服务器返回 Set-Cookie: token=xxx; HttpOnly; Secure，浏览器会自动在后续请求头带上 Cookie: token=xxx——这是 localStorage 和 sessionStorage 完全做不到的。

常见错误现象：localStorage.setItem('token', 'abc') 存了 token，但刷新页面后接口 401，因为后端根本没收到凭证；而 cookie（尤其带 HttpOnly）能天然配合后端鉴权流程。

cookie 是唯一能被浏览器自动携带进 HTTP 请求头的前端存储方式
若 token 存 localStorage，必须手动加到每个请求的 Authorization 头里（易漏、难维护）
HttpOnly cookie 无法被 JS 读取，能防 XSS 盗 token；但普通 cookie 或 localStorage 存 token，一旦 XSS 就大概率失守
cookie 总大小限制约 4KB/域名，别往里塞大对象；localStorage 虽有 5MB，但不能解决“自动发给后端”这个核心需求

`sessionStorage` 和 `localStorage` 的作用域陷阱

很多人以为同域名下所有标签页都能共享 sessionStorage，其实完全不能——它只绑定当前 tab 的顶级窗口。新开一个标签页、哪怕打开的是同一 URL，sessionStorage 也是全新的空仓库。

而 localStorage 确实同源共享，但要注意：iframe 同源时，父页和子 iframe 可以互相读写对方的 localStorage；但 sessionStorage 在 iframe 场景下是“同窗口内共享”，即父页 + 所有同源 iframe 共享一份（这点常被忽略）。

表单草稿、向导步骤状态等纯前端临时数据 → 用 sessionStorage，关掉当前页就清，不污染其他页
用户主题偏好、语言设置、长期缓存数据 → 用 localStorage，跨页生效，且刷新不丢
不要用 sessionStorage 做“单点登录状态同步”——A 标签页登录后，B 标签页查 sessionStorage 一定是空的
监听 storage 事件只能捕获其他同源窗口对 localStorage 的修改，对 sessionStorage 无效

存对象别直接 `setItem`，JSON 操作漏这一步就丢数据

localStorage 和 sessionStorage 只接受字符串作为值。如果直接 localStorage.setItem('user', { name: 'Alice' })，实际存进去的是 [object Object]，取出来 JSON.parse() 会报错。

正确做法永远是显式序列化和反序列化：

localStorage.setItem('user', JSON.stringify({ name: 'Alice', id: 123 }))  
const user = JSON.parse(localStorage.getItem('user') || '{}')

空值处理必须做：getItem 返回 null，直接 JSON.parse(null) 报错
日期、正则、函数等类型经 JSON.stringify 后会丢失，如需保存复杂结构，得自己封装序列化逻辑
cookie 没有内置 JSON 支持，更得手动 encodeURIComponent(JSON.stringify(...))，否则特殊字符导致截断或解析失败

兼容性与安全边界：别在老项目里默认用 `localStorage`

IE8+ 支持 localStorage，但 IE7 及更早不行；而 document.cookie 所有浏览器都支持。如果你的业务还要兼容 IE8 以下（极少见），cookie 是唯一选择。

但更大的问题是隐私模式：Safari 和部分 Chrome 隐私窗口下，localStorage 可能直接抛出 QuotaExceededError 或静默失败（尤其 iOS Safari）。这时不加 try/catch 就会导致关键逻辑中断。

生产环境操作 Web Storage 前务必包裹 try/catch，并提供降级方案（如内存变量缓存）
cookie 的 path 和 domain 设置影响作用域，比如 path=/admin 的 cookie 只在 /admin/* 路由下发送，容易配错导致后端收不到
移动端 WebView 对 storage 限制更严，某些安卓低版本 WebView 里 localStorage 容量可能远低于 5MB

真正卡住人的从来不是“哪个能存多久”，而是“谁在什么时候能看到它”“谁负责清理它”“出错了前端有没有兜底”。这些细节不写进代码注释，过三个月自己都得重读一遍 MDN。

今天关于《Cookie、SessionStorage和LocalStorage区别解析》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！