Cookie的SameSite三个取值怎么读：Strict、Lax与None的发送条件

如果你在开发者工具里看到一条Cookie带有SameSite属性，想知道它会不会跟着某个请求发出去，第一步不是看属性值，而是先判断这次请求属于同站还是跨站。

按MDN的说明，SameSite属性允许服务器指定是否、何时通过跨站点请求发送Cookie，其中站点由注册的域和方案（http或https）定义。这句话给出了两个判断维度：域和方案。只有域和方案都匹配，才算同站。

一个容易忽略的点：如果Cookie使用不同的方案发送，比如同一域名下http和https混用，按MDN的说明，它们不再视为来自同一站点。所以判断同站时，不能只看域名，还要看协议是否一致。

一个自建情境（示例，不是对某个真实网站的记录）：你在练习目录里用本地服务打开一个页面，页面里嵌入了一个指向example.test的图片。这个图片请求的域和方案与当前页面不同，属于跨站请求。下面所有判断都围绕这类跨站请求展开。

适用范围：本文只讲SameSite为Strict、Lax、None时Cookie在跨站请求中的发送条件，以及None必须同时设置Secure。不讲Cookie生命周期、不讲第三方跟踪法规。

Strict是最严格的一个取值。按MDN的说明，使用Strict时，Cookie仅发送到它来源的站点。

这句话可以这样理解：如果这次请求的目标站点和Cookie的来源站点不是同一个站点，Cookie就不会被发送。它不区分请求类型，也不区分是不是用户主动点击链接跳转过来的。

一个自建示例（练习数据）：假设你在练习目录里维护一个自建页面，服务器返回一条Cookie，属性写成：

Set-Cookie: mykey=myvalue; SameSite=Strict

当你在另一个站点上放一个指向这个练习页面的链接，点击后跳转过去，这次导航请求属于跨站请求，按Strict的规则，这条Cookie不会被带上。

所以读Strict时，判断顺序是：先确认请求是不是跨站，是跨站就不发送，不需要再问请求是怎么发起的。

Lax比Strict松一档。按MDN的说明，Lax与Strict相似，只是在用户导航到Cookie的源站点时发送Cookie，文档举的例子是通过跟踪来自外部站点的链接。

这句话的关键词是“导航”。它说的是用户在浏览器地址栏输入、点击链接跳转这类导航行为，而不是页面里自动发起的子资源请求。

一个自建示例（练习数据）：同样在练习页面里设置一条Cookie，属性写成：

Set-Cookie: mykey=myvalue; SameSite=Lax

当你在另一个站点上点击一个指向这个练习页面的链接，这次跳转属于导航到Cookie源站点，按Lax的规则，这条Cookie会被发送。

但如果那个外部页面上只是嵌入了一张来自练习站点的图片，浏览器自动去取这张图片，这属于子资源请求，不是用户导航，按Lax的规则，Cookie不会被带上。

所以读Lax时，判断顺序是：先确认是不是跨站，是跨站再问这次请求是不是用户导航到Cookie源站点，只有答案是“是”才发送。

None是三个取值里限制最少的一个。按MDN的说明，None指定浏览器会在同站请求和跨站请求下继续发送Cookie，但仅在安全的上下文中，也就是如果SameSite=None，还必须同时设置Secure属性。

这句话给了两个条件，缺一不可：SameSite=None，以及Secure。

一个自建示例（练习数据）：在练习页面里设置一条Cookie，属性写成：

Set-Cookie: mykey=myvalue; SameSite=None; Secure

这条Cookie在同站请求和跨站请求下都会被发送，但前提是这次请求走的是HTTPS。按MDN对Secure的说明，标记为Secure的Cookie只应通过被HTTPS协议加密过的请求发送给服务端，它永远不会使用不安全的HTTP发送（本地主机除外）。

所以读None时，判断顺序是：先确认Secure有没有同时设置，再确认这次请求是不是安全上下文。两个条件都满足，才谈得上跨站发送。

如果你在开发者工具里看到一条Cookie根本没有SameSite这一项，不要以为它不受限制。按MDN的说明，如果没有设置SameSite属性，则将Cookie视为Lax。

这句话对排查很有用。它意味着：一条没写SameSite的Cookie，在跨站导航到它源站点时会被发送，在跨站子资源请求里不会被发送，行为和显式写了SameSite=Lax一致。

MDN还提到，与SameSite相关的标准最近发生了变化，如果SameSite未指定，SameSite=Lax是新的默认值；以前默认情况下会为有请求发送Cookie。所以如果你在旧资料里看到“不写SameSite就等于全发送”的说法，那对应的是旧行为，不是当前文档记录的默认值。

一个自建示例（练习数据）：在练习页面里设置一条Cookie，只写名称和值，不写SameSite：

Set-Cookie: mykey=myvalue

按当前文档的默认值，读这条Cookie时应当按Lax的规则来判断它的发送条件，而不是按“没有限制”来判断。

需要说明的是，MDN提示具体浏览器版本中的处理方式可能不同，并建议查阅Cookie浏览器兼容性表。本文不给出各浏览器的版本对应关系。

把上面几节合起来，检查一条Cookie会不会随某个跨站请求发送，可以按下面四步走。以下核对顺序是编辑整理的检查方向，不是对某个真实网站的测试记录。

1. 看SameSite这一项写了什么。没写，按Lax处理。

2. 判断这次请求是同站还是跨站。按MDN的说明，站点由注册的域和方案定义，域和方案都匹配才算同站；方案不同（http与https混用）不再视为同一站点。

3. 如果是同站请求，三个取值下都会发送，不需要再往下判断。

4. 如果是跨站请求，按取值分别判断：Strict不发送；Lax只在用户导航到Cookie源站点时发送；None在同站和跨站都发送，但要先确认同时设置了Secure，且请求走的是安全上下文。

一个自建示例（练习数据）：在练习目录里准备两个页面，一个作为外部站点页面，一个作为Cookie源站点页面。在源站点页面里设置三条Cookie，分别写成SameSite=Strict、SameSite=Lax、SameSite=None; Secure。然后在外部站点页面里分别用链接跳转和图片嵌入两种方式指向源站点，观察开发者工具里每次请求带上了哪几条Cookie。

这个示例只用来观察发送条件，不涉及任何真实站点数据。

本文只讲SameSite为Strict、Lax、None时Cookie在跨站请求中的发送条件，以及None必须同时设置Secure这一条要求。

没有覆盖的内容包括：Cookie的生命周期（会话Cookie与持久Cookie的区别）、Domain和Path对发送范围的限定、HttpOnly属性、Cookie前缀（__Host-和__Secure-）、以及第三方跟踪相关的法规要求。这些内容各自回答不同问题，不在本文范围内。

另外需要说明：MDN提到与SameSite相关的标准最近发生了变化，并建议查阅Cookie浏览器兼容性表了解特定浏览器版本中的处理方式。本文不给出各浏览器的版本差异，也不把文档记录的规则当成所有浏览器的统一行为。

如果你要在自己的练习页面里验证这些规则，建议在单独的练习目录里操作，不要拿正在使用的站点配置直接改。