什么是 Cookie？浏览器 Cookie 详解

TL;DR：Cookie 是网站存在你浏览器里的一小段数据,通常只有几百字节,用于在请求之间记住信息。Cookie 支撑了登录、购物车和分析;它们也催生了如今被浏览器逐步收紧的跨站追踪时代。

Cookie 是一条 name-value 文本记录,网站通过 Set-Cookie HTTP 响应头在你的浏览器中设置它,浏览器再通过 Cookie 请求头自动把它附加到之后对同一域名的请求上。Cookie 是这个本无状态的 HTTP 网络上最早的状态机制——它早于 localStorage、IndexedDB、service worker 以及一切现代客户端存储方案。你遇到过的每一个 Cookie,从”保持登录”到询问你的欧盟同意横幅,都由这一个小协议管辖1。

简而言之：Cookie 是 HTTP 之上的一层薄薄的机制。服务器用 Set-Cookie: name=value 响应头设置一个;浏览器把它存进按域名的 Cookie 罐;之后每次匹配请求,浏览器把 Cookie: name=value 发回去。没有客户端握手——浏览器在 RFC 6265 的约束内服从服务器的指令。

Cookie 机制普遍归功于 Netscape 工程师 Lou Montulli,他在 1994 年为电商客户 MCI Net 解决”在页面之间记住购物车”的问题而引入了它2。三十年后,底层协议基本没变。正式规范是 IETF RFC 62651,并有一份正在演进的 IETF 草案3收紧安全和隐私边界。

一次最小的 Cookie 交换长这样:

# 服务器响应
HTTP/1.1 200 OK
Set-Cookie: sid=abc123; Path=/; HttpOnly; Secure; SameSite=Lax

# 客户端之后对同一站点的请求
GET /account HTTP/1.1
Cookie: sid=abc123

浏览器不解释 abc123 这个值——它对浏览器是不透明的。服务器才解释它（通常作为数据库会话键）。浏览器的职责是根据 Cookie 的 Domain、Path、Secure、SameSite 和过期属性,决定每次请求附带哪些 Cookie。

关键：Cookie 由服务器设置、由浏览器存储、在之后每次匹配请求时由服务器读取。浏览器是信使,不是作者。

简而言之：一个 Cookie 有一个必需部分（name=value）和服务器可设置的七个属性:Domain、Path、Expires、Max-Age、Secure、HttpOnly、SameSite。每个属性都收窄或限制浏览器何时把 Cookie 发回。

RFC 62651 及其 bis 修订3 定义的完整属性集:

  • Name 和 Value —— 唯一必需的一对。ASCII 文本。两者合计须装进约 4 KB4。
  • Domain —— 默认是发送 Set-Cookie 的主机。设 Domain=example.com 让 Cookie 应用于 example.com 及其所有子域。
  • Path —— 默认是请求路径所在目录。设 Path=/account 把 Cookie 限定到 /account 下的 URL。
  • Expires / Max-Age —— 日期或时长。两者都省略时,Cookie 是会话 Cookie（浏览器会话结束时删除）。Max-Age=0 立即删除该 Cookie。
  • Secure —— 设置后,浏览器只在 HTTPS 上发送该 Cookie。明文 HTTP 请求看不到它。
  • HttpOnly —— 设置后,页面里的 JavaScript 无法通过 document.cookie 访问该 Cookie。是对抗 XSS 窃取会话 Cookie 的主要防线。
  • SameSite —— Strict / Lax / None。管辖跨站请求行为（下文详述）。
  • Priority（Chrome 特有扩展）—— Low / Medium / High。提示浏览器在按域名 Cookie 罐满时优先驱逐哪些 Cookie。

简而言之：Cookie 沿两条正交的轴分类——生命周期（会话 vs 持久）和来源（第一方 vs 第三方）。一个 Cookie 在每条轴上总有一个取值。隐私法规和浏览器设置再叠加一套基于用途的分类（严格必要 / 功能 / 分析 / 广告）,就是你在同意横幅上看到的那些。

用户和监管机构常谈的 6 个常见类别,映射到底层协议:

类别生命周期来源典型用途浏览器默认策略（2026）
会话 Cookie会话第一方登录会话、当前购物车默认允许
持久第一方 Cookie持久第一方”记住我”、语言偏好默认允许
严格必要二者皆可第一方鉴权、防欺诈无需同意（GDPR）
功能 / 偏好持久第一方界面主题、字号建议同意（GDPR）
第一方分析持久第一方第一方分析欧盟需同意
第三方广告持久第三方广告定向、再营销、跨站标识Safari / Firefox 屏蔽;Chrome 受限5

英国信息专员办公室（ICO）简洁地概括了这一区别6:

严格必要的 Cookie 是为提供用户请求的在线服务所必需的。其余大多数 Cookie 在设置前需要知情同意。

简而言之：在协议层面 Cookie 是通用的 name-value 存储。实践中,网络把 Cookie 用于六类不同的任务,大致按对用户体验的重要程度递减排列。

现代网络上 Cookie 的六大主导用途:

  1. 鉴权与会话管理 —— 一个会话 ID Cookie,告诉服务器某个请求属于哪个已登录用户。几乎总是 HttpOnly、Secure、SameSite=Lax 或 Strict。
  2. CSRF 防护令牌 —— 服务器在状态变更请求时校验的随机防伪值。通常与一个隐藏表单字段配对。
  3. 购物车与未完成的工作 —— 在页面加载之间保留购物车内容和表单草稿。常是一个指向服务端状态的 ID。
  4. 用户偏好 —— 语言、主题、布局密度、无障碍设置。带数月到数年 Max-Age 的小型持久 Cookie。
  5. 第一方分析 —— 为 Plausible、Fathom 或自托管 PostHog（配置为基于 Cookie 时）做访客识别和会话计时。国内场景中,部分团队也会把第一方统计自托管以避免第三方追踪。
  6. 广告与跨站追踪 —— 广告网络、再营销方、分析平台设置的第三方 Cookie,需要跨多个站点识别同一用户。这是浏览器正在主动收紧的类别。

对开发者而言,实际含义是:你设置的大多数 Cookie 都应是第一方、限定到当前站点、标记 HttpOnly 和 Secure、并给 SameSite=Lax,除非你有需要 None 的特定跨站流程。

SameSite、HttpOnly、Secure —— 三个安全属性

简而言之：三个 Cookie 属性——SameSite、HttpOnly、Secure——各自防御一类不同的攻击。把这三个都设对,是服务器能做的杠杆最高的单项 Cookie 安全改进。

这三个属性构成现代 Cookie 安全基线。每个防御一类特定攻击:

  • Secure 防御被动网络嗅探。浏览器拒绝在明文 HTTP 上发送该 Cookie。任何持有会话状态的 Cookie 都必需,否则在开放 Wi-Fi 上窃取会话轻而易举。
  • HttpOnly 防御 XSS 驱动的会话窃取。通过跨站脚本漏洞注入页面的 JavaScript,无法经 document.cookie 读取 HttpOnly Cookie。服务器仍能看到它;攻击者的脚本看不到。
  • SameSite 防御 CSRF 和跨站追踪。三个取值:
    • SameSite=Strict —— Cookie 只在同站请求时发送。防护最强;有时不便（用户从别的站点点进你的域名,第一个请求会显示未登录）。
    • SameSite=Lax —— Cookie 在同站请求加上顶层跨站 GET 导航（点链接）时发送。Chrome 自 2020 年起的现代默认值7。
    • SameSite=None —— Cookie 在每个跨站请求时发送。正当的第三方 Cookie（单点登录、嵌入式支付挂件）需要它。必须与 Secure 配对。

Google 的 web.dev 指南在优先级上说得很明确7:“如果你今天只做一件事,就给每个会话 Cookie 设上 SameSite=Lax。“

第一方与第三方 Cookie,以及退役故事

简而言之：第一方 Cookie 由地址栏里的站点设置;第三方 Cookie 由代码运行在该站点上的另一个域名设置。第三方 Cookie 建起了现代广告追踪经济,现代浏览器正系统性地限制或消除它们。

第三方 Cookie 的收紧是该协议诞生以来对 Cookie 生态最具影响的变化。截至 2026 年中各浏览器现状:

  • Safari —— 自 Safari 11（2017）的 Intelligent Tracking Prevention（ITP）起默认屏蔽第三方 Cookie,并历经多轮收紧。
  • Firefox —— 自 2022 年起,在 Total Cookie Protection（TCP）下默认对第三方 Cookie 分区,实质上消除了跨站追踪。
  • Chrome —— 在多次推迟全面淘汰第三方 Cookie 后5,定为用户选择路线,以 Privacy Sandbox API 作为广告定向、归因、防欺诈的拟议替代。

对正当的跨站用例（联邦登录、嵌入式结账 iframe）,现代替代是 CHIPS —— Cookies Having Independent Partitioned State8。带 Partitioned 属性的 Cookie 按顶层站点分罐存储,因此在两个不同父站点下加载的同一 iframe 读不到同一个 Cookie。CHIPS 保留了”在这个挂件内记住设置”的正当用例,同时打断跨站标识流。

如果你维护的服务今天依赖第三方 Cookie,眼下的工作是审计你的 Cookie:哪些需要跨站可见（用 CHIPS）、哪些本就是为追踪设计的（在 Privacy Sandbox 或第一方数据上重建）。

简而言之：每个现代浏览器都能通过设置或开发者工具查看 Cookie。对可重复的工作流——调试会话 Bug、把 Cookie 导出为测试夹具、审计某站点存了什么——Manifest V3 扩展如 CookieVault Editor 是标准工具。下面的 8 步检查流程在每个 Chromium 浏览器上都适用。

在 Chrome 里查看和编辑 Cookie 的 8 步速查（Edge、Brave、Opera、Vivaldi、Arc 完全相同;Firefox 类似但菜单布局不同）:

  1. 在标签页打开目标站点。
  2. 按 F12 打开开发者工具。
  3. 点 Application 标签。
  4. 在左侧栏 Storage 下点 Cookies。
  5. 点域名查看范围内所有 Cookie。
  6. 双击某个单元格（Value、Expires、SameSite 等）就地编辑。
  7. 按 Enter 提交;浏览器立即应用。
  8. 刷新页面,下次请求即带上修改后的 Cookie。

批量删除 Cookie 见 Chrome 删除 Cookie 指南 的三种方法。想清追踪器又保留登录态见 清 Cookie 但保留登录态。想跨多站点一键可重复编辑,CookieVault Editor 是我们维护的开源 Manifest V3 工具。

简短澄清几条你可能在网上见过、但并不真实的说法:

  • “Cookie 是病毒” —— 错。Cookie 是被动文本记录,无法安装软件、运行代码或访问浏览器 Cookie 库之外的文件。
  • “Cookie 存你的密码” —— 几乎总是错。登录 Cookie 持有的是会话 ID,不是密码。密码一次性发给服务器、被哈希,服务器返回一个会话 ID Cookie。密码本身不在 Cookie 里。
  • “禁用 Cookie 就匿名了” —— 错。浏览器可通过许多不依赖 Cookie 的渠道被指纹识别（User-Agent、屏幕分辨率、字体、WebGL 哈希、IP 地址）。
  • “所有 Cookie 都跨站追踪你” —— 错。你正在访问的站点设置的第一方 Cookie 看不到你在别的站点。跨站追踪专门是第三方 Cookie 的问题。
  • “Cookie 在 GDPR 下违法” —— 错。Cookie 合法。GDPR（及 ePrivacy 指令）规制的是非必要 Cookie 的同意要求。严格必要的 Cookie 无需同意。
  • “清 Cookie 能修复一切浏览器问题” —— 部分对。清 Cookie 会重置会话和偏好状态,但修不了缓存资源、service worker Bug 或扩展冲突。

另见

Footnotes

  1. 当前 IETF 规范是 RFC 6265 ——“HTTP State Management Mechanism”,见 https://datatracker.ietf.org/doc/html/rfc6265。该文档定义 Set-Cookie 与 Cookie 头、Cookie 属性语义、存储模型和 Cookie 匹配规则。 ↩ ↩2 ↩3

  2. Mozilla 开发者网络的 HTTP cookies 参考 https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies 概括了现代 Cookie 属性集和浏览器端处理规则。1994 年的起源故事在网络史料中被广泛引用,可追溯到 Lou Montulli 在 Netscape 做”购物篮”功能的工作。 ↩

  3. Cookie 规范的演进版是 “RFC 6265bis”——正式名 draft-ietf-httpbis-rfc6265bis,由 IETF HTTP 工作组发布于 https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc6265bis/。它收紧前缀规则（`__Host-`、`__Secure-`）、正式化 SameSite、细化分区语义。 ↩ ↩2

  4. 每 Cookie 4 KB、每域名 50 个的数字是 RFC 6265 §6.1 的建议。真实浏览器限制约为建议下限的两倍,但因浏览器而异;Chrome 团队的 chrome.cookies API 参考 https://developer.chrome.com/docs/extensions/reference/api/cookies 记录了 Chrome 的实际限制。 ↩

  5. Chrome 的第三方 Cookie 立场多次变化。当前路线记录在 Privacy Sandbox https://developer.chrome.com/docs/privacy-sandbox/。该根路径下的状态页和各 API 文档追踪持续变化。 ↩ ↩2

  6. 英国信息专员办公室（ICO）在《隐私与电子通信条例》（PECR）下发布关于 Cookie 与同意的实务指南。ICO 多次重构该指南页、URL 不稳定;搜索 “ICO PECR cookies guidance”,或从 https://ico.org.uk 进入 “For organisations → Online tracking”。上文表格注释里转述的”严格必要”定义遵循 ICO 的表述。 ↩

  7. Google web.dev 的入门文《SameSite cookies explained》https://web.dev/articles/samesite-cookies-explained 是面向从业者的 SameSite 默认值与 Chrome 推出历史的权威参考。 ↩ ↩2

  8. CHIPS 规范——“Cookies Having Independent Partitioned State”——记录在 https://developer.chrome.com/docs/privacy-sandbox/chips。CHIPS 让跨站 Cookie 加入按顶层站点的分区,从而在第三方 Cookie 被屏蔽的情况下存活,而不支持跨站追踪。 ↩

最后更新:

作者: Lena Park · 审阅: Marcus Reiter