什么是 Cookie？浏览器 Cookie 详解

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

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

Cookie 如何工作

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

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

一次最小的 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 的构造

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

RFC 6265¹ 及其 bis 修订³ 定义的完整属性集:

• Name 和 Value —— 唯一必需的一对。ASCII 文本。两者合计须装进约 4 KB⁴。
• 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 的类型

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

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

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

严格必要的 Cookie 是为提供用户请求的在线服务所必需的。其余大多数 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 年起的现代默认值⁷。
  • SameSite=None —— Cookie 在每个跨站请求时发送。正当的第三方 Cookie（单点登录、嵌入式支付挂件）需要它。必须与 Secure 配对。

Google 的 web.dev 指南在优先级上说得很明确⁷:“如果你今天只做一件事,就给每个会话 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 后⁵,定为用户选择路线,以 Privacy Sandbox API 作为广告定向、归因、防欺诈的拟议替代。

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

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

如何查看、编辑、删除 Cookie

简而言之：每个现代浏览器都能通过设置或开发者工具查看 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 存你的密码” —— 几乎总是错。登录 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 或扩展冲突。

另见

• 如何在 Chrome 中删除 Cookie
• 清 Cookie 但保留登录态
• 如何在 Chrome 中编辑 Cookie
• 如何把 Cookie 导出为 JSON
• CookieVault Editor —— 开源 Manifest V3 Cookie 管理器
• CookieVault Guardian —— 关闭标签页自动删除 Cookie