Go net/http Cookie Partitioned 如何设置第三方隔离：SameSite 与浏览器兼容边界

在 Go 服务里给嵌入式组件保留登录态时，直接把 Cookie 标成 Partitioned 还不够：Go 会要求它同时带上 Secure，而浏览器是否把它当作 CHIPS 使用，还要看跨站场景下的 SameSite=None 和自身兼容性。更稳妥的做法是让服务端先生成一组满足约束的 Set-Cookie，再在真实浏览器里核对响应和降级路径。

Partitioned 解决的是“按顶级站点隔离存储”，不是“绕过第三方 Cookie 限制”；Go 负责序列化和基本校验，浏览器负责最终接受、分区和发送。

先看 Go 实际会发出什么响应头

下面的例子只做一件事：把一个嵌入式组件需要的短期状态写成响应 Cookie。__Host- 前缀、Path=/、不设置 Domain 是收紧范围的选择；真正决定分区的字段仍是 Partitioned。

package main

import (
    "fmt"
    "net/http"
)

func componentCookie() *http.Cookie {
    return &http.Cookie{
        Name:        "__Host-component_sid",
        Value:       "opaque-session",
        Path:        "/",
        Secure:      true,
        HttpOnly:    true,
        SameSite:    http.SameSiteNoneMode,
        Partitioned: true,
    }
}

func main() {
    cookie := componentCookie()
    fmt.Println(cookie.Valid())
    fmt.Println(cookie.String())
}

正常结果应先打印 ，随后得到包含 Path=/; Secure; HttpOnly; SameSite=None; Partitioned 的 Set-Cookie 值。顺序不是业务协议的判断依据，但这些属性是否齐全是判断配置是否成形的关键。

为什么 Partitioned 缺少 Secure 会直接失败

Cookie.Valid 的边界很明确：当 Partitioned 为真而 Secure 为假时，返回 http: partitioned cookies must be set with Secure。这不是浏览器静默拒绝后的猜测，而是服务端在发响应前就能发现的配置错误。

func validPartitionedCookie(c *http.Cookie) error {
    if !c.Partitioned {
        return nil
    }
    if !c.Secure {
        return errors.New("partitioned cookie must use Secure")
    }
    return nil
}

业务代码不必复制标准库的实现，但可以在测试里固定这个失败边界：

func TestPartitionedNeedsSecure(t *testing.T) {
    c := &http.Cookie{Name: "sid", Value: "x", Partitioned: true}
    if err := c.Valid(); err == nil {
        t.Fatal("expected Secure validation error")
    }
}

如果反向代理在 HTTPS 终止、应用内部仍按 HTTP 认知环境，应该先修正部署信任和 Cookie 配置，而不是删除 Secure 来“让测试通过”。

SameSite=None 和 Partitioned 解决的是两层问题

SameSite 控制 Cookie 是否随跨站请求发送；Partitioned 控制浏览器把它放进哪一个分区。对于确实需要在第三方嵌入上下文中工作的组件，常见组合是 SameSite=None; Secure; Partitioned。它表达的是“允许跨站使用，但按顶级站点隔离”，并不表达“所有站点共享一份登录态”。

假设 widget.example 被 site-a.example 嵌入后设置 Cookie，浏览器会把顶级站点纳入分区键；之后同一个组件出现在 site-b.example 时，不能因为 Cookie 名字相同就读到 A 的那份状态。这正是 CHIPS 与无分区第三方 Cookie 的差别。

把兼容性核对放在发布前

Go 的 Cookie.String 只能保证它把字段序列化成响应头；它不会替浏览器判断该版本是否支持 CHIPS，也不会为没有分区能力的浏览器创造等价的隔离语义。发布前至少做三组核对：

1. 服务端单元测试确认 Cookie.Valid 通过，并断言响应值包含 Secure、SameSite=None 和 Partitioned。
2. 用 HTTPS 在实际嵌入页面观察开发者工具中的 Set-Cookie、存储分区和后续请求；不要只看 Go 进程日志。
3. 为不支持或拦截分区 Cookie 的客户端准备不依赖跨站 Cookie 的降级路径，例如显式短期令牌或同站跳转建立会话。

降级路径不能把 A 站点的身份令牌直接复制到 B 站点。它应重新建立一次受控会话，并限制令牌用途、寿命和可访问范围。

常见问题：配置看似正确却没有状态

只设置 Partitioned，不设置 SameSite=None，可以吗？

Go 层面可以序列化，但跨站发送仍受 SameSite 策略影响。若业务确实是跨站嵌入，应显式评估 SameSite=None、HTTPS 和客户端策略，而不是把“能发出响应头”当成“浏览器一定会回传”。

为什么本地 HTTP 调试时 Cookie 不见了？

Secure 要求安全上下文；本地调试应使用可信的 HTTPS 开发入口，或在测试环境明确采用不启用 Partitioned 的替代配置。不要为了绕过本地问题修改生产契约。

Partitioned 能让多个顶级站点共享登录态吗？

不能。它的设计目标正是按顶级站点分开保存。需要跨站共享身份时，应采用明确的同意、跳转或后端会话交换流程。

最后的判断标准

看到 Partitioned 时，先沿着 Cookie.Valid、Cookie.String 和浏览器存储这条链核对，而不是只检查响应头里有没有一个单词。服务端满足 Secure，跨站场景明确 SameSite=None，浏览器端再验证顶级站点分区和降级行为，这样才能把配置正确与功能可用区分开。