跳转第三方域返回后Session Storage数据偶发丢失问题咨询

这不是代码逻辑疏漏，属于sessionStorage设计规则叠加现代浏览器安全/性能策略导致的已知现象，Chrome、Safari、Firefox的实现均符合W3C存储规范，不属于单个浏览器的bug。

• sessionStorage的作用域绑定规则本身就不支持跨顶级域名跳转的场景留存：按照规范，sessionStorage的生命周期严格绑定单个标签页的会话上下文，而非域名本身。
  • 若跳转第三方时触发了新标签页打开（无论是链接配置target="_blank"还是第三方站点的跳转逻辑主动开新页），新标签页加载你的域名时会创建全新的会话上下文，天然无法读取原标签页存储的sessionStorage；如果原标签页在后台因设备内存不足被浏览器进程回收，哪怕后续跳转回原标签页，原有会话上下文已经被销毁，存储的数据也会被清空。
  • 若在当前标签页直接跳转第三方域名，Safari的智能防跟踪（ITP）、Chrome的第三方存储分区、Firefox的增强型跟踪保护机制，会对跨顶级域名跳转的同域存储做隔离：当跳转链路中存在被标记为跟踪器的域名、或用户在第三方站点停留时长触发防跟踪阈值时，浏览器跳回你的域名时会初始化新的会话上下文，不会恢复之前存储的sessionStorage。
• 问题偶发的核心原因是上述策略的触发是有条件的：设备内存充足时后台标签页不会被回收，跳转链路耗时短未触发防跟踪阈值时数据就能正常读取，反之就会丢失，因此不会100%复现。

• 核心交易链路的临时数据不要依赖sessionStorage存储，根据数据敏感度选择对应方案：
  • 非敏感、需要链路透传的标识类数据：跳转第三方时将其拼接在跳转URL的参数中，要求第三方完成交易后跳转回你的站点时原封不动带回对应参数，注意对参数做签名校验避免被篡改。
  • 不适合暴露在URL中的非敏感临时数据：改用localStorage存储，存储时绑定唯一交易流水号作为key，交易完成后主动删除对应存储项，避免数据长期驻留。
  • 敏感交易状态类数据：不要在前端存储，跳转第三方前先将交易状态同步到自有服务端，和生成的唯一交易单号绑定，用户跳回站点时根据URL携带的交易单号从服务端拉取对应状态，这是兼容性、安全性最高的方案。
• 若要做兼容兜底，可在跳转第三方前通过Broadcast Channel将sessionStorage中的核心数据同步给同域下的其他常驻页面做临时备份，但该方案在浏览器开启强防跟踪模式下依然存在失效概率，不能作为唯一存储方案。

内容的提问来源于stack exchange，提问作者Ipsit Gaur