题目与使用场景
客服组件来自 support.example，会被 shop-a.example 和 shop-b.example 等顶级站点嵌入。组件需要在 shop-a.example 的商品页、结算页和帮助页之间保留会话；用户访问 shop-b.example 时应得到隔离状态。设计还要面对第三方 Cookie 默认受限、旧浏览器、退出登录、客服转人工和多标签页并发。
面试官考察什么
- 是否理解 CHIPS 以顶级站点和嵌入来源共同作为 Cookie 分区键。
- 能否区分“每个站点隔离的持久状态”和需要用户授权的未分区第三方状态。
- 是否能把 Cookie 设计、服务端会话、CSRF、防重放和注销流程连成完整数据流。
- 是否会处理能力检测、旧浏览器降级、缓存键和观测指标。
作答前的澄清问题
先确认所有嵌入是否使用 HTTPS、组件是否必须跨顶级站点识别同一用户、子域是否需要共享会话，以及是否允许弹出顶级站点登录页。再确认数据敏感级别、会话有效期、是否需要服务端推送和目标浏览器范围。若业务真的要求跨站统一身份，CHIPS 本身不满足该目标，应改用显式登录或授权流程。
30 秒回答框架
我会把会话定义为“顶级站点内的组件会话”。组件响应设置带 Partitioned 的安全 Cookie，服务端按顶级站点和组件会话解析状态；同一站点的子域共享该分区，另一个站点得到不同分区。Cookie 不能承担跨站身份，跨站登录改走顶级页面授权。对不支持 CHIPS 的浏览器，默认无持久会话，使用短期内存状态或显式打开组件站点完成授权。全链路验证注销、CSRF、缓存隔离和多标签页行为。
分步骤深入解答
- 定义信任边界。 组件服务只把嵌入站点当作分区上下文，不把
Origin字符串直接当作授权结论。服务端维护允许嵌入的站点清单，并校验消息来源、会话状态和租户。 - 设置分区 Cookie。 使用
Secure、合适的SameSite值和Partitioned属性；需要绑定当前主机时优先使用__Host前缀。Cookie 的逻辑键由嵌入来源和顶级站点共同决定，同一组件在两个顶级站点中不能读取同一份 Cookie。 - 设计服务端会话。 Cookie 只携带随机不可读标识，实际会话存储在服务端，记录租户、顶级站点、创建时间、过期时间和撤销版本。服务端每次请求都重新校验租户与会话绑定，避免只依赖浏览器分区。
- 处理子域和缓存。 顶级站点的多个子域可复用同一分区，但 HTML、脚本和 API 响应的缓存键不能遗漏租户或会话变化。个性化响应使用私有缓存或明确的
Vary策略，禁止 CDN 把一个站点的组件状态发给另一个站点。 - 设计登录和跨站授权。 需要识别同一用户时，让组件打开服务端的顶级页面完成登录，再通过一次性、有时效的授权码回传。不要把长期令牌放在 URL、
postMessage或未分区 Cookie 中。 - 建立降级与观测。 能力不足时以无会话模式运行，或提示用户进行显式授权；不能静默恢复未分区第三方 Cookie。记录分区 Cookie 命中率、授权成功率、会话创建和撤销原因，但日志不得包含 Cookie 值或用户令牌。
高质量示范回答
我会把 CHIPS 用在“同一顶级站点内保持组件状态”这个边界。support.example 为嵌入请求设置 Secure、SameSite=None 和 Partitioned 的 Cookie，Cookie 只保存随机会话标识；服务端会话表还绑定租户、顶级站点、过期时间和撤销版本。组件在 shop-a.example 的多个子域中复用同一分区，在 shop-b.example 中自然得到另一份状态。
跨站统一登录不依赖该 Cookie。组件打开顶级页面完成登录，经用户操作获得一次性授权码，再通过受校验的消息通道换取当前分区的短期会话。旧浏览器或策略阻止分区 Cookie 时，组件显示无会话体验或引导显式授权；不会回退到全局第三方 Cookie。验收覆盖两个顶级站点、多个子域、退出登录、过期、并发标签页、缓存、CSRF、消息伪造和浏览器隐私设置。依据包括 MDN 的 CHIPS 与 Storage Access API 文档，以及 Privacy Sandbox 的 CHIPS 说明。
常见错误
- 把
PartitionedCookie 当成跨站单点登录凭证，破坏了分区隔离目标。 - 只检查
Origin就授权，忽略租户、会话撤销、CSRF 和消息重放。 - 在不支持 CHIPS 时静默使用未分区第三方 Cookie，导致状态串站或被浏览器直接阻断。
- 忽略 CDN、Service Worker 或代理缓存键，把一个顶级站点的个性化响应复用给另一个站点。
- 把长期令牌放入 URL、
postMessage或前端可读 Cookie，扩大泄露面。
追问及应对
CHIPS 与 Storage Access API 什么时候分别使用？
CHIPS 适合每个顶级站点独立保存嵌入组件状态；Storage Access API 用于确有业务理由、并愿意让用户授权访问未分区第三方状态的场景，例如显式登录。两者的隐私边界不同，不能互相当作无感替代。
如何证明两个顶级站点的会话没有串联？
用相同浏览器分别嵌入组件，记录两个顶级站点的会话标识、服务端租户绑定和缓存命中结果。清除一个站点的 Cookie、退出登录、打开新标签页和切换子域后，另一个站点的状态都不应改变。
如果产品坚持跨站识别同一用户怎么办？
把需求升级为明确的身份授权流程：顶级页面登录、短期一次性授权码、服务端交换和可撤销会话。记录用户同意和失败原因，避免通过隐蔽的第三方追踪状态实现跨站关联。