Storage Partitioning 是现代浏览器默认启用的第三方上下文存储隔离机制，将 localStorage 按顶级站点与 iframe 源哈希分区，导致跨源嵌入时数据不互通；需用 Storage Access API 在用户手势下申请临时解除。
Storage Partitioning 是什么，为什么浏览器突然开始隔离你的 localStorage？
它不是你手动加的配置，而是现代浏览器（Chrome 89+、Edge 90+、Safari 15.4+）默认启用的第三方上下文存储隔离机制。当你在 iframe 中加载跨源页面（比如嵌入广告、登录组件、客服 widget），该子页面调用 localStorage.setItem() 时，实际写入的是一个按 top-level site + iframe source 哈希生成的独立分区，而非共享的全局 localStorage。
这意味着：同一域名 A 在主站和被 B 站 iframe 嵌入时，localStorage 数据完全不互通——不是“清空了”，是根本没写到同一个地方。
怎么确认自己正受 Storage Partitioning 影响？
打开 DevTools → Application → Storage → Local Storage，观察左侧来源列表。如果看到类似 https://example.com (partitioned: https://partner-site.com) 或带 hash 后缀的条目（如 https://example.com#1a2b3c），就说明已分区。此时直接在控制台执行：
localStorage.getItem('test')
可能返回 null，哪怕你在 iframe 里刚 set 过——因为当前上下文不是那个分区。
立即学习“前端免费学习笔记（深入）”；
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
- 主页面访问
localStorage→ 操作主域分区 - iframe（src="https://third.com"）内访问 → 操作
https://third.com在当前 top-level site 下的专属分区 - 没有显式 opt-out 机制，无法通过 JS 主动“关闭”分区
哪些场景会意外失效？怎么临时绕过（仅限开发/调试）？
典型翻车点：单点登录 token 同步失败、跨 iframe 的配置缓存丢失、埋点 ID 不一致。生产环境无法绕过，但本地调试可借助 Chrome 启动参数临时禁用：
--unsafely-treat-insecure-origin-as-secure="http://localhost:3000" --user-data-dir=/tmp/chrome-test --site-per-process --disable-features=PartitionedCookies,StoragePartitioning
注意：这仅用于验证是否为分区导致的问题，不可上线。Safari 和 Firefox 当前行为不同（Safari 更激进，Firefox 尚未默认启用），需单独测试。
- 不要试图用
postMessage+ 主页代理读写localStorage—— 分区后 iframe 里的localStorage对主站不可见 - 避免依赖
localStorage做跨上下文状态同步；改用postMessage显式传递必要数据 - 服务端下发的 token、用户身份等关键状态，优先走 URL 参数或 HTTP-only Cookie（配合 SameSite 策略）
长期方案：用 Storage Access API 申请临时解除分区限制
当 iframe 确实需要读写其“原始”存储（例如嵌入的支付组件要复用用户偏好），必须由用户手势触发，并显式请求权限：
if ('storageAccess' in document) {
try {
await document.requestStorageAccess();
// 此时 localStorage / IndexedDB 恢复为非分区行为
localStorage.setItem('payment-theme', 'dark');
} catch (err) {
// 用户拒绝，或不在合法上下文（如无点击事件）
}
}
关键约束：
- 必须在用户手势（click/tap）事件处理函数中调用，不能异步延迟
- 只对当前文档生效，且仅持续到页面卸载或用户关闭 tab
- Chrome 要求 iframe 的
allow="storage-access-api"属性已声明 - Safari 强制要求 top-level site 与 iframe 同一注册域（eTLD+1），否则直接拒绝
分区不是 bug，是隐私保护的必然走向。真正难的不是绕过，而是把“存储即全局”的旧假设，换成“存储需声明、需授权、需显式同步”的新模型。
