chrome默认启用第三方存储分区，可通过chrome://flags验证状态或开发者工具application面板观察“third-party”标识；调试时可添加--disable-features参数临时禁用。
当你在网页中使用 iframe 嵌套第三方站点（比如嵌入广告、统计脚本或登录组件），却发现 localStorage、IndexedDB 或 Cookie 数据无法在主站与嵌套页间共享，甚至开发者工具 Application 标签页明确提示 “Is third-party: Yes, because the origin is outside of the top-level site”，这说明 Chrome 已默认启用实验性第三方存储分区（Storage Partitioning），它正主动隔离跨源存储——而你要做的不是“开启”，而是确认其生效状态、理解其行为边界，并在必要时临时禁用以调试兼容性问题。
确认 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_MACHINE\SOFTWARE\Policies\Google\Chrome。
新建 DWORD (32-bit) 值，命名为 ThirdPartyStoragePartitioningEnabled，数值数据设为 0。
重启 Chrome 后，该策略将覆盖所有用户配置，使第三方存储分区全局失效。
