cookie
Cookie 属性详解表格
| 属性 (Attribute) | 作用 (Purpose) | 示例 (Example) | 备注 (Remarks) |
|---|---|---|---|
| Name=Value | 【必须】 设置 Cookie 的名称和值 | session_id=abcdef123 | 这是 Cookie 的核心部分，也是唯一强制要求的部分。 |
| Expires | 【生命周期】 设置 Cookie 过期的具体日期（绝对时间） | Expires=Wed, 21 Oct 2025 07:28:00 GMT | 正在被 Max-Age 取代。若不设置，则为会话 Cookie。 |
| Max-Age | 【生命周期】 设置 Cookie 的存活时间（相对时间，单位秒） | Max-Age=3600 (1小时后过期) | 优先级高于 Expires。0 表示立即删除；负数表示会话 Cookie。 |
| Domain | 【作用域】 指定 Cookie 生效的域名（及其子域） | Domain=example.com | 不设置则默认为当前主机（不含子域）。 |
| Path | 【作用域】 指定 Cookie 在指定域名下生效的 URL 路径 | Path=/ | 不设置则默认为当前路径。Path=/ 最常用，表示全站可用。 |
| Secure | 【安全】 标记该 Cookie 只能通过 HTTPS 连接发送 | Secure | 防止中间人攻击窃听。对于敏感信息（如会话令牌）是必需的。 |
| HttpOnly | 【安全】 禁止通过客户端脚本 (JavaScript) 访问该 Cookie | HttpOnly | 有效防止 XSS 攻击窃取 Cookie，极大地提升了安全性。 |
| SameSite | 【安全】 控制在跨站请求中是否发送 Cookie，用于防御 CSRF 攻击 | SameSite=Lax | 有三个值： • Strict : 最严格，完全禁止跨站发送。 • Lax : (浏览器默认值) 允许部分顶层导航的跨站请求发送。 • None : 允许所有跨站请求发送，但必须同时设置 Secure 属性。 |
SameSite=Lax
SameSite=Lax 的规则是：
- 对于同站请求，总是发送 Cookie。
- 对于跨站请求 ，只有当这个请求是**
安全的顶层导航**时，才会发送 Cookie。
这里的"安全的"通常指 GET 请求。
场景一：Lax 允许发送 Cookie （好的用户体验）
假设你正在浏览一个新闻网站 news.com，看到一篇文章提到了你在 github.com 上的一个项目，并附上了链接。
-
你的状态：你之前登录过 github.com，所以你的浏览器里存着 github.com 的登录 Cookie。
-
你的操作：你在 news.com 上点击了这个链接，跳转到 github.com。
-
请求分析：
- 这是一个跨站请求 (从 news.com -> github.com)。
- 这是一个顶层导航 (因为你点击了链接，地址栏的 URL 变了)。
-
Lax 的行为 ：浏览器判断这符合规则，于是会把 github.com 的 Cookie 带上。
-
结果：你跳转到 GitHub 页面时，你依然是登录状态。体验非常流畅。
如果这里用的是 SameSite=Strict，Cookie 就不会被发送，你跳转过去就变成未登录状态了，需要重新登录，体验就会变差。
场景二：Lax 阻止发送 Cookie （提升安全性）
假设一个黑客在自己的恶意网站 hacker.com 上放置了一个隐藏的表单，这个表单会自动向你的银行网站 my-bank.com/transfer 发送一个 POST 请求，企图把你的钱转走。
-
你的状态：你刚登录过 my-bank.com，浏览器里存着银行的登录 Cookie。
-
你的操作：你无意中访问了 hacker.com。
-
请求分析：
- 这是一个跨站请求 (从 hacker.com -> my-bank.com)。
- 这不是一个顶层导航 (它是一个由脚本在后台发起的 POST 请求，你的地址栏没变)。
-
Lax 的行为 ：浏览器判断这不符合"顶层导航"的条件，于是不会发送 my-bank.com 的 Cookie。
-
结果 ：银行服务器收到了转账请求，但因为请求里没有 Cookie，它无法识别你的身份，于是拒绝了该请求。你的资金是安全的。这就成功防御了一次 CSRF (跨站请求伪造) 攻击。
总结
所以， "允许部分顶层导航的跨站请求发送" 的意思是：
SameSite=Lax 在安全性和用户体验之间做了一个非常聪明的权衡。它阻止 了那些通常被用于 CSRF 攻击的后台跨站请求（如 、、AJAX POST），但允许了那些用户主动发起的、体验上需要保持登录状态的跨站页面跳转（如点击链接）。
这就是为什么现代浏览器选择它作为默认值的原因------它在不破坏大多数正常网页浏览体验的前提下，极大地提升了 Web 的安全性。
什么是"顶层导航"？
简单来说，顶层导航 就是指那些会改变浏览器地址栏 URL 的用户操作。
当你进行以下操作时，就触发了顶层导航：
- 点击一个普通的
<a>链接。 - 提交一个
<form method="GET">的表单。 - 在浏览器地址栏输入网址后按回车。
与之相对的，不是 顶层导航的请求通常发生在页面内部或后台，不会改变地址栏的 URL。例如：
-
通过
<img>标签加载一张图片。 -
通过
<iframe>嵌入一个页面。 -
通过 AJAX 或 fetch() API 发起一个网络请求。
-
通过
<script>标签加载一个脚本。SessionStorage
SessionStorage vs. LocalStorage vs. Cookie
这张表格可以非常清晰地展示它们之间的区别：
| 特性 | SessionStorage | LocalStorage | Cookie |
|---|---|---|---|
| 生命周期 | 标签页关闭后即失效 | 永久存储，除非手动清除 | 可设置过期时间，否则随浏览器关闭失效 |
| 作用域 | 单个标签页 | 同源的所有窗口/标签页 | 同源且符合 Path 规则的所有请求 |
| 数据共享 | 仅限当前标签页，标签页间不共享 | 同源的所有标签页共享数据 | 同源的所有标签页共享数据 |
| 与服务器通信 | 不参与 | 不参与 | 自动随每次同源 HTTP 请求发送 |
| 存储容量 | 较大 (5-10MB) | 较大 (5-10MB) | 很小 (约 4KB) |
| API | 简洁易用 (setItem, getItem等) | 与 SessionStorage 相同 | 原始，需手动封装 (document.cookie) |
| 主要用途 | 临时、标签页级别的状态管理 | 需要长期保存的客户端数据 | 身份认证、会话跟踪 |