localStorage和sessionStorage有什么区别：从作用域和生命周期判断

如果你在自己的实验页里同时打开两个不同源的页面，会发现它们各自看到的数据不一样。按 MDN 的说明，sessionStorage 为每一个给定的源维持一个独立的存储区域，localStorage 同样按源隔离。也就是说，同一个源下的页面才能读到同一份数据，不同源之间互不可见。

这一点决定了你排查问题的方向：如果数据“丢了”，先确认当前页面和写入数据的页面是不是同一个源。协议、主机、端口三者中任意一项不同，就属于不同源。

一个自建情境（示例，不是对某个真实网站的记录）：你在练习目录里放两个 HTML 文件，用本地地址打开，一个写入数据，另一个读取。如果两个文件通过同一个本地服务打开，它们同源，能互相读到；如果其中一个换成 example.test 上的地址，就不同源，读不到。

适用范围：本文只讲在自建实验页里用无敏感数据观察作用域和生命周期，不涉及跨域技巧，也不建议把密码或 Token 存进这两种存储。

这是两者最关键的区别。按 MDN 的说明，sessionStorage 的数据在页面会话期间可用，也就是只要浏览器处于打开状态，包括页面重新加载和恢复；数据会一直存储到浏览器或选项卡关闭。localStorage 做同样的事，但即使浏览器关闭并重新打开也仍然存在。

把这句话拆成两个动作来理解：

1. 关闭标签页或选项卡。sessionStorage 的数据随之清除；localStorage 的数据不受影响。

2. 关闭整个浏览器再重新打开。sessionStorage 的数据清除；localStorage 的数据仍然在。

所以判断该用哪一个，先问一句：这份数据需不需要在用户下次打开浏览器时还在。需要，用 localStorage；只在当前这次浏览里有效，用 sessionStorage。

一个自建情境（示例）：你在实验页里放两个按钮，一个写入 sessionStorage，一个写入 localStorage，各写一个自建字符串。然后关闭标签页再重新打开同一地址，观察哪一份还在。这个观察只用于理解生命周期，不代表对任何真实站点的测试。

sessionStorage 的清除时机由会话结束触发，你不需要额外设置。localStorage 则不同：按 MDN 的说明，存储的数据没有过期日期，只能通过 JavaScript、清除浏览器缓存或本地存储的数据来清除。

这句话给了一个重要提醒：localStorage 不会自己过期。如果你写入后不主动删除，它会一直留在那台设备的那个源下。所以写入前要想清楚两件事：这份数据要不要留、留多久。

在自建实验页里，可以用 Storage 对象的方法主动清理，例如按名删除或整体清空。下面是一个自建示例，只操作你自己实验页里的无敏感数据：

// 写入一个自建示例值
localStorage.setItem("demoTheme", "light");

// 读取
console.log(localStorage.getItem("demoTheme"));

// 按名删除
localStorage.removeItem("demoTheme");

// 清空当前源下的全部 localStorage
localStorage.clear();

注意最后一行会清掉当前源下所有 localStorage 项，练习时不要在有其他重要数据的源下执行。

按 MDN 的说明，Web Storage 的存储限额大于 cookie，最大 5MB；localStorage 的存储限额是两者之间的最大值。资料没有给出更细的分项数值，也没有给出不同浏览器的具体配额表，所以本文不补这些数字。

对初学者来说，可操作的理解是：这两种存储适合放少量、结构简单的数据，不适合当数据库用。如果你要存的内容明显偏大，先考虑换一种方案，而不是反复试探上限。

一个自建情境（示例）：你在实验页里写入一段自建的长文本，观察写入是否成功。这个动作只用于感受“有限额”这件事，不代表对任何浏览器配额的测量。

另外，MDN 提到在 Firefox 中，当浏览器崩溃或重新启动时，为了避免过度使用 Web storage 导致的内存问题，每个源的存储大小将限制在 10M。这条备注针对特定情况，不要把它当成所有浏览器的通用数值。

如果你在隐私窗口、隐身模式或类似名称的隐私浏览选项里打开实验页，会看到另一种行为。按 MDN 的说明，隐私窗口不会存储历史记录和 cookie 等数据；在隐身模式下，localStorage 被视为 sessionStorage。存储 API 仍然可用且功能齐全，但当浏览器或浏览器选项卡关闭时，所有存储在隐私窗口中的数据都会被删除。

这意味着：在隐私窗口里，localStorage 的“长期保留”特性不成立。如果你在隐私窗口里做实验，看到 localStorage 的数据在关闭后消失，这不是代码写错了，而是这个模式的行为。

一个自建情境（示例）：你在普通窗口和隐私窗口里分别写入同一个自建键值，关闭后重新打开，对比两者的结果。这个对比只用于理解模式差异，不代表对任何真实站点的记录。

MDN 还有一条备注：若用户禁用第三方 cookie，那么将不允许来自第三方 iframe 对 Web Storage 的访问。

这条限制影响的是嵌入在别人页面里的第三方 iframe 场景。如果你在自己的实验页里把页面嵌进另一个源的 iframe，而浏览器设置又禁用了第三方 cookie，那么 iframe 里的脚本可能读不到 Web Storage。

对初学者来说，可操作的做法是：先确认你观察的页面是不是被嵌在第三方 iframe 里，再确认浏览器的相关设置。不要一遇到读不到数据就改代码，先排除这一层限制。

一个自建情境（示例）：你在练习目录里放一个父页面和一个子页面，把子页面用 iframe 嵌进父页面，观察子页面里的脚本能否访问存储。这个观察只用于理解限制条件，不代表对任何真实站点的测试。

把前面的信息整理成一个可执行的判断顺序：

1. 这份数据要不要在关闭浏览器后还在？要，选 localStorage；不要，选 sessionStorage。

2. 这份数据要不要在同一个源的多个标签页之间共享？localStorage 按源共享，sessionStorage 按标签页会话隔离。需要跨标签页读到同一份数据，用 localStorage；只在当前标签页有效，用 sessionStorage。

3. 这份数据是不是密码、Token 或其他敏感信息？如果是，两种存储都不建议用。资料说明这两种机制的数据永远不会被传输到服务器，但这不等于它们适合存放敏感信息。本文只建议在自建实验页里用无敏感数据练习。

一个自建情境（示例）：你在实验页里放一个自建的“主题偏好”字符串，用 localStorage 存，观察关闭浏览器后重新打开是否还在；再放一个自建的“本次浏览计数”，用 sessionStorage 存，观察关闭标签页后是否清零。这两个例子都只使用无敏感数据。

最后提醒：动手前先备份你实验页里已有的内容，所有写入和清除操作都只在你自己的练习页里做，不要拿正在使用的页面直接试。