浏览器存储分区与隐私
了解顶层站点如何隔离嵌入式浏览器状态，以及应用流程如何适应分区存储。
在会分区处理嵌入状态的浏览器中，顶层站点可能是分区边界的一部分：同一嵌入来源在不同顶层站点下可能遇到彼此分开的浏览器管理状态。这可以减少一部分跨站状态共享，但具体 API、分区细节和例外因浏览器及版本而异。产品应明确哪些状态需要共享、哪些必须分开，以及组件在新上下文没有旧状态时如何提示用户。
分区是浏览器的隐私与兼容性行为，不代表完全隔离，也不会阻止所有数据交换。浏览器可能为部分嵌入存储提供由用户决定的访问机制，但能否使用及其范围取决于浏览器规则。浏览器管理的存储与应用、服务器的数据流不同。应用不应从嵌入存储读取成功或失败推断个人或设备身份。
分区键改变了什么
Cookie、脚本创建的 storage 及其他客户端状态可以关联到包含顶层站点的分区。MDN 状态分区概览介绍了嵌入资源的通用模型。Privacy Sandbox 存储分区说明了 Chromium 隐私语境中的同类边界。具体 API 和访问规则取决于浏览器与版本。
因此，同一来源的嵌入服务在站点 A 与站点 B 下可能遇到不同状态。在一个上下文创建的 consent、缓存偏好或 session 可能在另一个上下文不可用。这是按上下文隔离状态的结果，不一定是应用失败。组件应提供清楚的首次使用路径，并说明用户何时需要再次选择账户或偏好。
顶层导航与嵌入有不同存储关系。服务作为主站点打开时使用第一方上下文，嵌入其他页面时则受嵌入规则影响。支持两种流程的产品应分别测试，不能因为第一方登录成功就假定嵌入登录拥有相同状态。
分区还可能影响 service worker、cache、IndexedDB 和客户端偏好。依赖另一上下文缓存的 worker 可能需要再次下载。已在其他位置选择的模型或语言偏好也可能看似不存在。明确哪些资源可以重新下载、哪些选择需要再次询问，以及如何在不丢失当前任务的情况下说明新上下文。
当嵌入组件在不同 tab、window 或应用路由之间移动时，边界会更明显。用户认出同一个服务，却可能看到新的 consent 状态。界面应说明恢复连续性的动作，例如打开服务页或再次选择账户，不要让用户猜测是浏览器问题、session 过期还是新上下文。
使用嵌入 SDK 的团队应随 SDK 版本记录存储假设。组件更新可能改变 key、cache 格式或申请访问的时机。为草稿和偏好保留迁移路径，并测试中断更新。比较浏览器和 SDK 同时更新的结果时，应保留应用版本和 fixture。
各项观察能说明什么
- 存储分区： 自有嵌入 frame 在站点 A 下能读到合成值、在站点 B 下读不到，与分区隔离相符；但这不能识别个人，也不能证明所有 API 都已分区。可在两个上下文中比较同一来源 frame 的写入和读取结果。Privacy Sandbox 以 Local Storage 和 IndexedDB 等存储 API 说明了这一边界。
- 服务器端授权： 请求得到允许的响应，只能说明服务器按测试账户和适用策略接受了这次请求；不能说明浏览器存储没有分区，也不能证明其他接口获准访问。可比较一个获准和一个未获准测试请求的响应。
- Storage Access 例外： Storage Access API 请求成功，说明该文档在此上下文获得了访问；不能证明访问永久有效或适用于所有情况。可记录 API 结果，并在自有测试 frame 中观察一次后续存储读取。
- 嵌入数据流： 观察到请求，只能说明本次测试中有哪些数据到达该目标；不能说明没有其他数据发送，也不能说明服务器如何保留数据。可检查一条自有请求的目标和合成负载，并与用户明确选择的内容对照。
嵌入应用设计
先从用户流程开始，而不是从某个 storage API 开始。决定组件要记住 consent、保存草稿、显示登录状态，还是只展示公开内容，并说明每项状态在哪个上下文有效。小而明确的状态记录比假设所有 iframe 共享账户更容易解释。
如果流程需要第一方关系，应提供通往服务自身页面的可见路径。用户可以在那里检查账户、consent 或设置。返回嵌入页面时，应通过明确 handoff 继续任务，而不是依赖未说明的共享 cookie。
嵌入组件应把空分区视为正常状态。需要时显示登录或设置动作，短暂保留非敏感输入，并说明偏好为何不存在。不要静默复制其他顶层站点的状态，明确选择才能让数据边界易懂。
权限提示应提供以用户为中心的回退。如果浏览器提供嵌入访问机制，应说明组件需要什么以及将共享什么。用户拒绝后，页面的无关功能仍应可用，不要重复提示或暗示必须授权才能阅读公开内容。
存储分区不能替代服务器授权。服务仍需在服务器验证账户权限和请求完整性。客户端存储只是便利和缓存，不能作为登录证明。嵌入 session 过期时，应显示可恢复状态并请求正确动作，不要把缺少 cookie 当成浏览器身份证据。
隐私与数据最小化
分区可以减少不同顶层站点之间的被动状态共享，但不使所有嵌入交互都私密。嵌入服务仍会收到渲染功能所需的请求数据，顶层页面也能观察它放入页面的内容。应审查 URL 参数、postMessage、网络请求、服务器日志、分析、下载和删除的完整数据路径。
只收集嵌入任务需要的状态。控制本地显示的偏好通常可以留在分区，不必附带账户标识。草稿可能需要保留期和清除动作。支持记录通常只需结果与应用版本，不需要整个 storage 数据库。
不要把存储可用性变成稳定身份信号。缺少 key 可能表示新上下文、清空 profile、浏览器设置、拒绝 permission 或应用变化；存在 key 也可能只是第一方关系。用功能结果选择路径，并在诊断用途结束后删除状态。
第三方内容的所有者可能不同于顶层应用。合同应说明谁管理账户数据、consent、支持访问和保留期限。嵌入支付、媒体或身份组件需要服务边界时，应在数据离开页面前告知用户。分区不能回答谁能看到提交值。
Cookie 管理指南介绍 session 状态和保留选择。Storage quota 与隐私讨论容量观察。不要把这些主题与分区键混在一起：quota 结果不能证明顶层上下文，分区也不是额外收集 quota 测量值的理由。
测试分区状态
使用两个自有顶层测试站点和一个自有嵌入服务。先用干净 profile 确定初始状态。在站点 A 下设置合成偏好，再在站点 B 下重复。预期应写成用户规则，例如“每个站点都有自己的 consent”，而不是浏览器身份判断。
第一方与嵌入流程要分别验证。第一方访问测试常规账户和设置；嵌入访问测试空分区、拒绝访问和返回服务页的路径。fixture 使用合成数据，不要向测试端点发送真实账户或文档。
覆盖状态生命周期：新上下文、浏览器重启、清除站点状态、改变 consent、session 过期和应用更新。检查产品是保留输入、请求选择，还是有意重新开始。重置后不能仍显示旧操作已完成。
跨 frame 通信应是明确且有限的任务协议。双方验证消息来源和含义，不要用宽泛消息通道重建隐藏的全局存储。用户选择第一方页面时，可传递有明确寿命且由服务器授权的短 handoff 引用。
在不把一次结果当作通用规则的前提下测试浏览器差异。记录浏览器族、版本、顶层站点、嵌入来源、应用版本和功能结果。支持变化可能需要可见回退或说明更新，不代表所有版本采用同一分区策略。
排查兼容性
嵌入组件显示未登录时，先确定上下文是顶层还是嵌入、干净还是已有，以及哪个站点拥有它。再检查应用 session 过期、服务器授权、consent 和网络响应。不要先复制 cookie 或合并 profile。
组件应区分空分区和网络失败。两者都可能表现为缺少偏好，但用户动作不同：空上下文需要设置，网络失败需要重试，权限撤销需要解释。
缓存会让变化看似不一致。service worker 或应用 cache 可能保留旧壳，而新分区获取当前资源。为资源设置版本，处理更新中断，并在新 cache 下载期间保留可用路径。不要仅因新上下文没有缓存，就删除唯一可用的本地草稿。
可选嵌入功能在存储不可用时不应阻塞整页。可以提供第一方路径、本地非账户路径或说明不可继续的功能。远程回退必须在上传前显示，并说明保留规则。
支持证据应保持小规模。记录受影响任务、顶层上下文、嵌入来源类别、浏览器版本、应用版本和可见结果。只有小记录无法解释时才通过授权流程请求底层数据，并在案例结束删除临时证据。
发布审查与运维
浏览器版本、嵌入 SDK、consent 流程、账户系统或存储 schema 变化时，重新测试同一合成流程。比较可见结果和用户需要的动作，不要猜测内部分区键。
为支持的浏览器族和嵌入流程保留兼容矩阵。可列出第一方登录、嵌入首次使用、consent 恢复、草稿保留和第一方 handoff，并写明所有者和复查日期。不要记录测试期间创建的每个 storage 值。
为曾经跨上下文可用的状态写迁移规则。更新前用户可能需要再次选择偏好、在服务页登录或导出草稿。提供明确动作并保留旧路径一段时间，避免静默丢失。不要合并无关顶层站点的记录。
事故处理要保护用户工作。分区变化中断草稿时，尽量在当前上下文保留输入，提供用户控制的导出或第一方继续路径，并说明任何上传。修复不应要求收集无关浏览历史或永久关闭隔离。
浏览器或集成更新后，应在每个受支持的嵌入上下文中重复一次合成草稿流程。新分区应显示初次设置，而不是错误地宣称旧草稿已经保存；原始草稿必须保留到用户选择的导出或第一方页面续接完成。先将应用和依赖版本与之前成功的运行对照，再判断失败是否来自浏览器存储。
运维所有权还包括删除。明确用户如何清除嵌入草稿、支持人员如何删除临时测试记录，以及退役集成如何停止接收请求。验证用户可见的确认，并在服务无法加载旧偏好时仍保留删除动作。
提供第一方继续流程时，应在跳转前显示数据边界。说明草稿是留在设备、转入账户还是上传到服务，并在用户确认结果前保留原始输入。浏览器上下文变化应成为可理解的产品动作，而不是静默的数据转移。
分析系统也要理解分区。同一嵌入服务出现在两个顶层站点时，可能形成两份本地状态，但这不代表两个人。围绕已完成的应用事件、consent 和获准观察的服务关系定义指标，不要为了恢复跨站视图而拼接分区标识。需要汇总报告时，应记录测量目的、限制保留期，并验证每个受支持上下文中的退出与删除。
账户恢复需要独立测试。用户失去嵌入 session 后，应能进入自有恢复页面，同时保留在顶层应用已输入的工作。handoff 必须过期、不能在 URL 暴露 credential，并且只返回继续任务所需的结果。覆盖取消、handoff 过期、登录了其他账户以及浏览器重启，并让每个结果都有清楚的下一步。
无障碍检查应覆盖上下文转换和初始组件。嵌入面板需要设置时要向辅助技术报告；第一方继续完成后，把焦点移到有意义的标题；用户返回时保留键盘位置。错误文本要区分拒绝访问、状态过期和服务不可用，并提供与其他登录或设置流程相同的名称、状态消息和恢复控件。
兼容性结论应被视为带日期的观察。记录浏览器版本和实际测试的自有流程，并在浏览器、身份提供方、嵌入 SDK 或 consent 模型变化时复查。公开说明应写明受支持任务与回退路径，不猜测内部实现。这样即使不同浏览器通过不同 API 或发布节奏实现相似隐私目标，指导仍然可用。
