localStorage vs sessionStorage1. 它们是什么二者都属于Web Storage API都是浏览器提供的键值对存储Key-Value。只支持存字符串对象需要JSON.stringify/parse。同源策略限制同协议 同域名 同端口才能互相访问。2. 核心差异对比表格维度localStoragesessionStorage生命周期长期除非手动清除代码删除/用户清理浏览器数据会话级关闭当前标签页/窗口即清除刷新页面保留保留关闭标签页保留清除新开同域标签页可共享同源下可读同一份不共享每个标签页独立容量大致通常 5MB 左右各浏览器实现有差异通常 5MB 左右各浏览器实现有差异APIsetItem/getItem/removeItem/clear同localStorage典型用途记住登录态、主题设置、长期偏好临时表单草稿、一次性流程状态、单标签页会话缓存3. 代码层面的共同点3.1 写入与读取// 写入localStorage.setItem(token,xxx)sessionStorage.setItem(token,xxx)// 读取constt1localStorage.getItem(token)constt2sessionStorage.getItem(token)// 删除localStorage.removeItem(token)sessionStorage.removeItem(token)3.2 存对象需要序列化constuser{id:1,name:Alice}localStorage.setItem(user,JSON.stringify(user))constparsedJSON.parse(localStorage.getItem(user)||null)4. “点击刷新仍保持登录态”的关键点刷新会导致 JS 内存状态如 Pinia/Vuex/组件 state全部丢失。只要 token 存在于持久化存储中localStorage或sessionStorage应用重新加载后仍能读到 token并在请求拦截器里带上。区别在于用localStorage关闭浏览器/标签页后再次打开仍可保持登录除非 token 过期或被清理。用sessionStorage关闭当前标签页就需要重新登录。5. 登录态场景怎么选5.1 管理后台常见选择localStorage原因管理后台用户通常希望“记住登录态”避免频繁登录。支持多标签页共享同一登录态同源下。方法登录成功后setToken(token)写入localStoragerequest.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 放在服务端下发的HttpOnlyCookieJS 不可读但这会带来CSRF 防护需求SameSite、CSRF Token 等与后端鉴权方式的配套改造7. 实用选型建议想要“关闭浏览器/标签页后仍记住我”选localStorage或更安全的 Cookie 方案。想要“关闭标签页就退出”选sessionStorage。临时状态一次流程、草稿优先sessionStorage。不管选哪个都需要重视 XSS 风险登录态过期时要做一致的清理与跳转。
localStorage vs sessionStorage
localStorage vs sessionStorage1. 它们是什么二者都属于Web Storage API都是浏览器提供的键值对存储Key-Value。只支持存字符串对象需要JSON.stringify/parse。同源策略限制同协议 同域名 同端口才能互相访问。2. 核心差异对比表格维度localStoragesessionStorage生命周期长期除非手动清除代码删除/用户清理浏览器数据会话级关闭当前标签页/窗口即清除刷新页面保留保留关闭标签页保留清除新开同域标签页可共享同源下可读同一份不共享每个标签页独立容量大致通常 5MB 左右各浏览器实现有差异通常 5MB 左右各浏览器实现有差异APIsetItem/getItem/removeItem/clear同localStorage典型用途记住登录态、主题设置、长期偏好临时表单草稿、一次性流程状态、单标签页会话缓存3. 代码层面的共同点3.1 写入与读取// 写入localStorage.setItem(token,xxx)sessionStorage.setItem(token,xxx)// 读取constt1localStorage.getItem(token)constt2sessionStorage.getItem(token)// 删除localStorage.removeItem(token)sessionStorage.removeItem(token)3.2 存对象需要序列化constuser{id:1,name:Alice}localStorage.setItem(user,JSON.stringify(user))constparsedJSON.parse(localStorage.getItem(user)||null)4. “点击刷新仍保持登录态”的关键点刷新会导致 JS 内存状态如 Pinia/Vuex/组件 state全部丢失。只要 token 存在于持久化存储中localStorage或sessionStorage应用重新加载后仍能读到 token并在请求拦截器里带上。区别在于用localStorage关闭浏览器/标签页后再次打开仍可保持登录除非 token 过期或被清理。用sessionStorage关闭当前标签页就需要重新登录。5. 登录态场景怎么选5.1 管理后台常见选择localStorage原因管理后台用户通常希望“记住登录态”避免频繁登录。支持多标签页共享同一登录态同源下。方法登录成功后setToken(token)写入localStoragerequest.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 放在服务端下发的HttpOnlyCookieJS 不可读但这会带来CSRF 防护需求SameSite、CSRF Token 等与后端鉴权方式的配套改造7. 实用选型建议想要“关闭浏览器/标签页后仍记住我”选localStorage或更安全的 Cookie 方案。想要“关闭标签页就退出”选sessionStorage。临时状态一次流程、草稿优先sessionStorage。不管选哪个都需要重视 XSS 风险登录态过期时要做一致的清理与跳转。