Go http.Cookie 的 Partitioned 怎样组合 Secure 和 SameSite

如果你在 Go 中把 http.Cookie.Partitioned 设为 true，最重要的组合规则只有一句：必须同时设置 Secure: true。SameSite 解决的是跨站请求时是否发送 Cookie，它和 Partitioned 不是同一个开关。

官方资料：https://pkg.go.dev/net/http#Cookie

推荐的基础组合是 Secure: true、SameSite: http.SameSiteNoneMode、Partitioned: true。先让 Cookie.Valid() 通过，再交给 http.SetCookie 写入响应。

先分清 Partitioned、Secure 和 SameSite

这三个字段经常被一起修改，但职责完全不同。Secure 表示 Cookie 只能通过安全连接发送；SameSite 控制跨站请求的发送策略；Partitioned 表示浏览器按顶级站点等分区保存这类 Cookie。Go 标准库只负责解析、校验和序列化字段，不替浏览器决定最终的存储和发送行为。

标准组合：先 Valid，再写入响应

下面的组合适合需要跨站上下文、同时希望使用分区 Cookie 的场景。这里的重点不是把字段堆在一起，而是先调用 Valid，让标准库在写响应前暴露不合法组合。

package main

import (
	"fmt"
	"net/http"
)

func buildCookie() (*http.Cookie, error) {
	cookie := &http.Cookie{
		Name:       "embed_session",
		Value:      "session-value",
		Path:       "/",
		Secure:     true, // Partitioned Cookie 的硬性前置条件。
		HttpOnly:   true, // 阻止页面脚本直接读取会话值。
		SameSite:   http.SameSiteNoneMode, // 允许需要跨站发送的场景。
		Partitioned: true, // 请求浏览器使用分区存储。
	}
	if err := cookie.Valid(); err != nil {
		// 先校验组合，避免把无效属性静默带到响应层。
		return nil, fmt.Errorf("cookie 配置无效: %w", err)
	}
	return cookie, nil
}

func handler(w http.ResponseWriter, r *http.Request) {
	cookie, err := buildCookie()
	if err != nil {
		http.Error(w, "cookie 配置错误", http.StatusInternalServerError)
		return
	}
	// SetCookie 会把 Cookie.String() 的结果写成 Set-Cookie 响应头。
	http.SetCookie(w, cookie)
	fmt.Fprintln(w, "ok")
}

在这个例子中，Valid 只检查 Go 结构体本身是否满足规则；它不会替你验证浏览器、反向代理或实际站点关系。SameSite=None 也不能替代 Secure，两者需要分别表达业务策略和传输约束。

为什么 Partitioned 没有 Secure 时会失败

Go 源码中的校验规则是：当 Partitioned 为 true 而 Secure 为 false 时，Valid 返回“partitioned cookies must be set with Secure”。这条规则直接对应 Partitioned Cookie 的安全前提。

func invalidCookie() error {
	cookie := &http.Cookie{
		Name:        "bad_session",
		Value:       "value",
		SameSite:    http.SameSiteNoneMode,
		Partitioned: true,
		// 故意省略 Secure，Valid 会返回错误。
	}
	return cookie.Valid()
}

func showHeader() string {
	cookie := &http.Cookie{
		Name:        "embed_session",
		Value:       "value",
		Path:        "/",
		Secure:      true,
		SameSite:    http.SameSiteNoneMode,
		Partitioned: true,
	}
	// String 只负责序列化；生产代码仍应在此之前调用 Valid。
	return cookie.String()
}

第二个函数序列化出的核心属性顺序会包含 Secure; SameSite=None; Partitioned。不要只因为 String 返回了非空字符串，就把它当成完整的业务验证；对外写响应前仍应保留 Valid 这一步。

SameSite 该选什么：看发送场景，不看 Partitioned 字段

SameSite=Lax、Strict 和 None 代表不同的跨站发送策略。若你的请求必须在跨站上下文携带该 Cookie，通常需要评估 SameSite=None，并同时保留 Secure=true；若业务只需要同站访问，就不要为了“看起来完整”强行设成 None。

这也是排查“浏览器没有带 Cookie”时的分界线：先看响应头中是否有 Secure 与 Partitioned，再根据请求是否跨站检查 SameSite。Go 的 CookieJar 和浏览器实现还可能有各自的策略，不能把服务端序列化结果当成客户端最终发送保证。

发布前的四项排查清单

1. 如果 Partitioned=true，确认 Secure=true，并让 Cookie.Valid() 先通过。
2. 根据是否需要跨站发送选择 SameSite，不要把它当成 Partitioned 的别名。
3. 检查最终 Set-Cookie 是否包含预期的 Secure、SameSite 和 Partitioned 属性。
4. 把 Go 标准库校验、代理改写和浏览器策略分开排查，避免只看服务端代码就下结论。

一句话总结：Partitioned 决定分区存储，Secure 是它的强制搭配，SameSite 决定跨站发送策略。先按这三个职责构造 Cookie，再用 Valid 和响应头复查，问题通常就能定位在具体一层。

相关问题

Partitioned 为 true 时 SameSite 必须是 None 吗？Go 的 Cookie.Valid 直接强制的是 Secure；SameSite 仍应按实际跨站发送场景选择，不能把业务策略简化成一个固定字段。

为什么 Cookie.String 没报错，但请求还是不带 Cookie？String 只负责生成字符串。还要继续检查 HTTPS、跨站关系、代理改写和客户端 Cookie 策略。

服务端只调用 http.SetCookie 可以吗？可以写出响应头，但建议先调用 Valid，这样配置错误会在响应发送前变成明确错误。