先别急着找“开启”按钮——Chrome 默认自 95 版本起就已经把第三方存储分区（Storage Partitioning）给安排上了。

你更多时候要做的，是确认它到底有没有生效，理解它怎么影响你的 iframe 嵌套页面，并在调试兼容性问题时，知道怎么临时关掉它。

不然呢？遇上跨站 localStorage 或 IndexedDB 数据死活共享不了，八成就是它在背后“作祟”。

举个例子：你在主站 a.com 嵌了一个 b.com 的 iframe，结果发现 localStorage 写入的内容在父页面读不到。

开发者工具 Application 标签页里还明确标着“Is third-party: Yes, because the origin is outside of the top-level site”。

这可不是什么 bug，而是 Chrome 主动隔离了跨源存储。下面我们就一步步把这事整明白。

确认 Storage Partitioning 当前是否已启用

Chrome 自 95 版本起默认启用该机制，无需手动开启。但不同版本策略细节有差异，必须验证当前生效状态。

操作步骤：

• 在地址栏输入 chrome://flags 并回车，进入实验性功能页面。
• 在顶部搜索框中输入 third-party storage partitioning，页面将高亮显示 “Experimental third-party storage partitioning” 条目。
• 观察其右侧下拉菜单当前值：
  • 【Enabled】 表示已激活（Chrome 默认值）；
  • 【Disabled】 表示已被人工关闭；
  • 若为 【Default】，则取决于 Chrome 版本及底层策略，需结合下一步判断。

注意：该选项在 Chrome 115+ 中已从 flags 页面移除，转为强制启用。此时搜索无结果即代表已深度集成，不可通过 flags 关闭。

在开发者工具中识别分区行为

打开一个含跨源 iframe 的网页（例如主站 a.com，嵌入 b.com 的 iframe），按 F12 打开开发者工具。

切换到 Application → Storage 面板，左侧会列出多个 origin 条目。

其中 b.com 的条目旁会标注 “Third-party” 字样，且其 localStorage/Cache API 数据与 a.com 完全独立——这就是分区生效的直接证据。

如果你在 iframe 内执行 localStorage.setItem('test', '1')，再在父页面执行 localStorage.getItem('test') 返回 null，这不是 bug，而是分区机制在正常工作。

这一步不需要任何设置，纯观察行为；若未看到 Third-party 标注，说明当前环境（如旧版 Chrome 或企业策略覆盖）未启用该特性。

临时禁用 Storage Partitioning（仅限调试）

此操作仅用于本地开发调试，切勿在日常浏览中长期禁用，否则将削弱对跨站追踪和存储劫持的防护能力。

方法一：通过启动参数绕过（Windows/Linux）

• 关闭所有 Chrome 进程。
• 右键桌面 Chrome 快捷方式 → 属性 → 在“目标”末尾添加空格后追加：--disable-features=PartitionedCookies,ThirdPartyStoragePartitioning。
• 点击确定保存，双击该快捷方式启动 Chrome，再用 chrome://version 查看“Command Line”字段，确认参数已生效。

方法二：注册表强制策略（Windows 企业环境）

• 按 Win+R 输入 regedit → 导航至 HKEY_LOCAL_MACHINESOFTWAREPoliciesGoogleChrome。
• 新建 DWORD (32-bit) 值，命名为 ThirdPartyStoragePartitioningEnabled，数值数据设为 0。
• 重启 Chrome 后，该策略将覆盖所有用户配置，使第三方存储分区全局失效。

《夸克》非常好用的免费AI浏览器

下载APP查看