sessionstorage是浏览器提供的临时存储机制，数据生命周期绑定当前标签页，关闭即清除。1.用于跨页面或刷新后保持临时数据，如多步骤表单暂存、spa状态管理；2.区别于localstorage，sessionstorage仅在当前会话有效且作用域限于当前标签页；3.使用时需注意：仅存储非敏感信息，防止xss攻击；处理容量限制，避免超限错误；遵守同源策略；手动序列化对象；避免滥用导致状态混乱。
JavaScript的sessionStorage，简单来说，就是浏览器提供的一种本地存储机制，它的数据生命周期与当前会话（或更准确地说，是当前浏览器标签页）紧密绑定。这意味着，只要你不关闭这个标签页或浏览器，数据就一直都在；一旦关闭，数据就会被清空。它不像localStorage那样永久保存，也不像Cookie那样每次请求都自动发送到服务器，更不会有烦人的过期时间设置。它就是为“当前”这个时刻，这个具体标签页的临时数据而生。
解决方案
当我们需要在用户的当前浏览会话中，跨页面或在页面刷新后依然保持一些数据时，sessionStorage就显得特别有用。它属于Web Storage API的一部分，提供了一组非常直观的键值对存储接口。
使用起来，它的核心方法和localStorage几乎一模一样，非常友好：
立即学习“Java免费学习笔记（深入）”；
-
存储数据：sessionStorage.setItem(key, value)
// 存储一个字符串 sessionStorage.setItem('username', 'Alice'); // 存储一个对象 const userSettings = { theme: 'dark', notifications: true }; sessionStorage.setItem('settings', JSON.stringify(userSettings)); -
获取数据：sessionStorage.getItem(key)
- 根据key获取对应的value。如果key不存在，返回NULL。
- 获取到的值也是字符串，如果是之前用JSON.stringify()存储的对象，需要用JSON.parse()解析回来。
const username = sessionStorage.getItem('username'); // 'Alice' const settingsString = sessionStorage.getItem('settings'); if (settingsString) { const settings = JSON.parse(settingsString); console.log(settings.theme); // 'dark' } -
删除单个数据：sessionStorage.removeItem(key)
- 根据key删除对应的数据项。
sessionStorage.removeItem('username'); -
清空所有数据：sessionStorage.clear()
- 清除当前域下sessionStorage中的所有数据。这个操作要慎重，因为它会把所有东西都抹掉。
sessionStorage.clear();
-
获取存储项数量：sessionStorage.Length
- 返回当前sessionStorage中存储的键值对数量。
const count = sessionStorage.length;
-
遍历所有存储项：sessionStorage.key(index)
- 通过索引获取对应的键名，然后可以再用getItem获取值。
for (let i = 0; i < sessionStorage.length; i++) { const key = sessionStorage.key(i); const value = sessionStorage.getItem(key); console.log(`${key}: ${value}`); }
sessionStorage的数据是同源的，也就是说，只有来自同一个协议、域名和端口的页面才能访问彼此的sessionStorage数据。而且，每个浏览器标签页都有自己独立的sessionStorage实例，一个标签页的sessionStorage不会影响到另一个标签页。这其实是个非常重要的特性，保证了不同会话之间的隔离性。
sessionStorage与localStorage有哪些核心区别？我该如何选择？
这两兄弟，sessionStorage和localStorage，都是Web Storage API的成员，用起来感觉几乎一样，但它们的核心差异在于数据的“生命周期”。这就像是你在办公桌上放东西，有些东西是临时的，会议结束就收起来；有些东西是常驻的，你每天都要用。
核心区别：
-
数据生命周期：
- sessionStorage： 数据只在当前浏览器会话中有效。当你关闭浏览器标签页（或者浏览器本身），sessionStorage中的数据就会被清除。如果你在一个标签页打开了网站，然后又在新标签页打开了同一个网站，这两个标签页的sessionStorage是相互独立的，互不影响。
- localStorage： 数据是永久性的，除非你手动清除，或者用户清除浏览器缓存，否则数据会一直存在。即使你关闭浏览器再重新打开，数据也还在那里。
-
作用域：
- sessionStorage： 作用域是当前标签页。每个标签页都有自己的sessionStorage实例，互不干扰。
- localStorage： 作用域是整个浏览器。同一个域名下的所有标签页，共享同一个localStorage数据。
如何选择？
选择哪个，完全取决于你的数据需要“活”多久，以及它的“作用范围”是多大。
-
选择sessionStorage的场景：
- 临时表单数据保存： 用户填写到一半的表单，不小心刷新了页面，或者跳转到其他页面又返回，希望表单数据还在。这简直是sessionStorage的完美用例。
- 单页应用(SPA)中的会话状态： 比如用户在某个模块的筛选条件、列表的滚动位置、或者某个组件的临时状态，这些只需要在当前浏览会话中保持，关闭标签页就无所谓了。
- 临时性的用户偏好设置： 比如用户在当前会话中选择了某个主题模式，但并不希望这个选择被长期记住。
- 防止重复提交： 在用户提交表单后，可以设置一个标记到sessionStorage，防止用户在短时间内重复提交。
-
选择localStorage的场景：
- 用户登录信息或Token： 用户登录后，通常希望下次打开浏览器还能保持登录状态。
- 用户个性化设置： 比如网站主题、字体大小、语言偏好等，这些希望长期记住的设置。
- 离线缓存数据： 某些不经常变动的数据，可以缓存到localStorage，减少网络请求，提升加载速度。
- 用户浏览历史或足迹： 比如用户最近浏览过的商品列表。
我的经验是，如果数据仅仅是为了提升当前用户体验，或者在特定流程中需要临时传递，且不希望它在用户关闭页面后依然存在，那就果断选择sessionStorage。如果数据是用户永久性的配置，或者希望在用户下次访问时依然有效，那么localStorage才是你的首选。
在实际开发中，sessionStorage有哪些常见的应用场景？
sessionStorage虽然生命周期短，但正因如此，它在很多需要“临时性”数据存储的场景中，表现得非常出色，而且避免了localStorage可能带来的数据积累问题。
-
多步骤表单的数据暂存： 想象一个注册流程，分了好几步，每一步用户填写一部分信息。如果用户在第三步不小心刷新了页面，或者中途需要去其他页面查个资料再回来，你总不希望他从头再填吧？这时，每完成一步，就把当前步骤的数据存入sessionStorage。当用户回到这个表单页面时，检查sessionStorage是否有数据，有就填充进去。这样，即使页面刷新或导航，用户体验也不会中断。
// 在表单输入框失去焦点时保存 document.getElementById('step1_input').addEventListener('blur', function() { sessionStorage.setItem('step1Data', this.value); }); // 页面加载时恢复 window.addEventListener('load', function() { const savedData = sessionStorage.getItem('step1Data'); if (savedData) { document.getElementById('step1_input').value = savedData; } }); -
单页应用 (SPA) 中的视图状态管理： 在React、vue或angular这类SPA框架中，页面切换通常不触发整页刷新。但如果你在某个列表页滚动到了底部，或者应用了复杂的筛选条件，然后跳转到详情页，再返回列表页时，你可能希望列表页的滚动位置和筛选条件依然保持。由于SPA的路由切换可能导致组件重新渲染，直接的JS变量会丢失，但sessionStorage可以作为一种轻量级的状态持久化方案。
// 保存滚动位置 window.addEventListener('beforeunload', () => { sessionStorage.setItem('scrollPos', window.scrollY); }); // 恢复滚动位置 window.addEventListener('load', () => { const scrollPos = sessionStorage.getItem('scrollPos'); if (scrollPos) { window.scrollTo(0, parseInt(scrollPos)); sessionStorage.removeItem('scrollPos'); // 用完就清掉，避免干扰其他会话 } }); -
防止重复提交： 用户提交表单后，如果网络延迟或者用户手抖多点了几次提交按钮，可能会导致数据重复提交。一个简单的策略是，在第一次提交成功后，在sessionStorage中设置一个标记（比如sessionStorage.setItem(‘formSubmitted’, ‘true’)），并在接下来的几秒内，如果再次点击提交，就检查这个标记，如果存在就阻止提交。这个标记只在当前会话有效，避免了长期存储的副作用。
-
临时性的用户偏好或A/B测试标记： 有时候，你可能想在用户当前会话中，临时改变一些界面元素或功能，比如进行A/B测试。你可以根据用户第一次访问时随机分配的A/B组，将结果存储在sessionStorage中，确保用户在当前会话中始终看到同一个测试版本，而不会因为刷新页面而切换。这比用cookie更简洁，且不会发送到服务器。
这些场景都体现了sessionStorage“短暂且专一”的特点，它只关心当前这个标签页，当前这个会话的数据，一旦任务完成或会话结束，数据就随风而逝，不留痕迹，这正是它价值所在。
使用sessionStorage时，有哪些需要注意的安全问题和最佳实践？
虽然sessionStorage用起来很方便，但它毕竟是客户端存储，有些方面还是需要我们多留心，避免踩坑。
-
安全性考量：切勿存储敏感信息！ 这是最重要的一点。sessionStorage中的数据是完全暴露在客户端的，任何通过浏览器开发者工具都能轻易查看和修改。更糟糕的是，如果你的网站存在XSS（跨站脚本攻击）漏洞，恶意脚本可以轻而易举地读取、修改甚至删除sessionStorage中的所有数据。所以，像用户的密码、银行卡号、个人身份信息等任何敏感数据，绝对不能明文存储在sessionStorage中。即使是加密后存储，也要极其谨慎，因为密钥通常也在客户端，容易被逆向工程。
-
容量限制：sessionStorage的存储容量通常在5MB到10MB之间，这取决于不同的浏览器。虽然比cookie的4KB大很多，但如果你尝试存储非常大的数据，比如图片二进制数据或者大型JSON对象，很可能会超出限制，导致写入失败并抛出错误。所以，在使用setItem时，最好用try…catch块包裹起来，以优雅地处理可能的存储失败。
try { sessionStorage.setItem('largeData', JSON.stringify(someVeryLargeObject)); } catch (e) { if (e.name === 'QuotaExceededError') { console.error('SessionStorage 容量超出限制！', e); // 提示用户或采取其他降级措施 } else { console.error('存储数据时发生未知错误：', e); } } -
同源策略：sessionStorage严格遵守同源策略（Same-Origin Policy）。这意味着只有来自相同协议、域名和端口的页面才能访问彼此的sessionStorage。这是浏览器提供的一道安全屏障，防止恶意网站窃取你网站的数据。你不需要为此额外做什么，但了解这一点可以帮助你理解为何在某些跨域场景下无法访问sessionStorage。
-
多标签页独立性： 我们之前提过，每个标签页的sessionStorage都是独立的。这既是优点，也可能是需要注意的地方。如果你期望用户在不同标签页之间共享某些临时状态，sessionStorage就无法满足了，你需要考虑使用localStorage或者更复杂的跨标签页通信机制（如BroadcastChannel API）。
-
数据类型处理：sessionStorage只能存储字符串。如果你想存储JavaScript对象、数组、数字或布尔值，你必须手动进行序列化（JSON.stringify()）和反序列化（JSON.parse()）。忘记这一步会导致你存储的数据变成[object Object]或字符串化的数字，而不是你期望的类型。
// 错误示范：直接存储对象 sessionStorage.setItem('myObject', { a: 1, b: 2 }); // 实际存储的是 "[object Object]" // 正确做法：序列化 sessionStorage.setItem('myObject', JSON.stringify({ a: 1, b: 2 })); const retrievedObject = JSON.parse(sessionStorage.getItem('myObject')); console.log(retrievedObject.a); // 1 -
避免滥用： 虽然方便，但不要把sessionStorage当成万能的临时数据库。只存储那些真正需要跨页面或刷新后短暂保留的数据。过度使用或存储不必要的数据，不仅可能触及容量上限，也可能让你的应用状态管理变得混乱。保持数据的精简和目的性，是任何存储策略的最佳实践。
总结来说，sessionStorage是一个强大且实用的工具，尤其适用于管理会话级别的临时数据。但前提是你清楚它的限制、安全边界，并遵循一些基本的最佳实践。它不是万金油，但用对了地方，能极大地提升用户体验和开发效率。
