将您的网站转换为分区 Cookie 时，如果任何给定客户端同时存在同名的分区和未分区 Cookie，您都可能会遇到意外行为。
设置分区 Cookie 不会替换或替换同名的现有未分区 Cookie。只要启用了第三方 Cookie，两者都存在，但它们位于不同的 Cookie JAR 中。停用第三方 Cookie 后，系统仅接受已分区的 Cookie。如果两个 Cookie 同时存在，系统就无法以编程方式判断哪个已分区，哪个没有，这可能会导致意外行为。
解决此问题的方法有两种： 1. 使您要替换的 Cookie 过期 2. 重命名 Cookie
主要注意事项
在改用分区 Cookie 时，请注意以下几点：
- 您无法以程序化方式确定 Cookie 是已分区还是未分区。不过，您可以在 Chrome 开发者工具中确定 Cookie 的分区状态。
- 分区 Cookie 不会覆盖未分区的 Cookie。如果两个 Cookie 完全相同（即具有相同属性（例如名称、网域或路径）的 Cookie），只要其中一个 Cookie 具有
Partitioned属性，系统就会将其视为不同的 Cookie。 - 最好避免在同一网络调用中返回具有相同名称的分区 Cookie 和未分区 Cookie。
使您要替换的 Cookie 过期
如果您的网站或服务无法应对名称的变更，您可以在现有的未分区 Cookie 失效时创建新的分区 Cookie。虽然无法确定 Cookie 是否已分区，但不带 Partitioned 属性的 Set-Cookie 标头不会影响未分区的 Cookie。
以下示例展示了如何使名为 example 的未分区 Cookie 失效，并让任何分区 Cookie 不受影响，即使它们具有相同的名称也是如此。系统将添加或更新名为 cookieName 的新分区 Cookie（如果已存在）。
Set-Cookie: example=-1;HttpOnly;SameSite=None;Secure;Max-Age:0
Set-Cookie: cookieName=value;Secure;SameSite=None;MaxAge=34560000;Partitioned
重命名 Cookie
确保无缝转换的最可靠方法是为分区和未分区 Cookie 使用不同的名称。例如，如果您有一个名为“example”的未分区 Cookie，则可以将其迁移到分区 Cookie。
Set-Cookie: example-partitioned=value;Secure;SameSite=None;MaxAge=34560000;Partitioned
由于 Cookie 的有效期并非以编程方式公开，因此无法将新 Cookie 的有效期设置为与未分区 Cookie 的有效期一致。在此过程中，更新 Cookie 的值可能比较实用。
维护分区 Cookie 和未分区 Cookie
在过渡期间，请考虑维护两个单独的已分区 Cookie：一个已分区，另一个未分区。例如，您可能同时拥有 auth 和 auth-partitioned Cookie，其中后者使用 Partitioned 属性进行设置。
每次该值更新时，您都应尝试设置这两个 Cookie。
- 在已阻止第三方 Cookie 但尚不支持 CHIPS 的客户端上：两种 Cookie 都不会被接受。
- 在阻止第三方 Cookie 和支持 CHIPS 的客户端上：
authCookie 将被拒绝，但auth-partitionedCookie 会被接受。 - 在不阻止第三方 Cookie 的客户端上，无论它们是否支持 CHIPS：
auth和auth-partitioned都会被接受。
当您的应用需要读取身份验证 Cookie 时，您应该先查找 auth-partitioned；但如果您必须临时回滚更改，可以回退到查找 auth Cookie。
当您确定大多数用户的 Cookie 均已刷新后，就可以停用 auth-partitioned Cookie，并将 Partitioned 属性添加到常规身份验证 Cookie 中。