〇、前言
前文已经介绍了*，单击查看全部系列文章：缓存Storage，*那么本文再介绍另一新的类别：身份与会话管理。
身份与会话管理，涵盖 Cookies 和 Private state tokens。
- Cookies 是最早的客户端存储机制，每次请求都会自动携带，适合服务器端识别用户身份或维持会话；
- Private state tokens 是为替代第三方 Cookie 而设计的隐私保护方案，用于在不追踪用户的前提下验证用户行为（如：防欺诈），属于现代隐私沙盒的一部分。
下面来详细介绍下。
一、什么是 Cookies？
1.1 简介
Cookie 是服务器通过 HTTP 响应头发送至浏览器、存储在用户本地设备上的小型文本数据文件，主要用于识别用户身份、维持会话状态及记录用户偏好。其核心作用是解决 HTTP 协议的无状态特性，使网站能够"记住"用户行为。
三个特点：
- 数据形式：以键值对（如：username=John）存储的纯文本文件，仅能被创建它的服务器读取。
- 存储位置：由浏览器管理，不同浏览器路径不同（如：Chrome 存储在 Cookies 文件中），用户无法直接通过 JavaScript 修改非 HttpOnly 属性外的 Cookie 内容。
- 自动传输：浏览器在后续同域请求中自动将 Cookie 附加到 HTTP 请求头，服务器通过解析识别用户身份。
两种生命周期类型：
- 会话 Cookie：无明确过期时间，仅在浏览器会话期间有效（关闭浏览器后自动删除），常用于临时状态管理（如：购物车）。
- 持久 Cookie：通过 Max-Age 或 Expires 属性设置过期时间（如：7 天），关闭浏览器后仍长期有效，用于"记住登录"等场景。
实际上，Cookie 并非传统意义上的"缓存"（如：资源复用），而是会话状态管理工具，需谨慎处理敏感信息。用户可通过浏览器设置管理或删除 Cookie，但禁用必要 Cookie 可能导致部分功能失效。开发者应优先使用 HttpOnly + Secure + SameSite=Strict 组合，最大限度保障安全性。
1.2 按照功能可以分为三类：必要、功能、追踪
1）必要 Cookie（Essential / Strictly Necessary Cookies）
这个类别是网站正常运行的"基础设施"，也是网站提供用户明确要求的服务所绝对不可或缺的。
三个主要作用：
会话管理：维持用户的登录状态，防止用户在浏览不同页面时被反复要求重新登录。
安全与验证：防范跨站请求伪造（CSRF）攻击，验证用户身份，保障支付和表单提交的安全性。
负载均衡：将用户的请求分配到不同的服务器，确保网站在高并发下的稳定性。
根据 GDPR（通用数据保护条例）等隐私法规，必要 Cookie 通常不需要获取用户的明确同意即可部署，但必须在隐私政策中向用户声明。
生命周期特点：绝大多数是会话级 Cookie（Session Cookie），在用户关闭浏览器后会自动删除，不会长期驻留。
2）功能 Cookie（Functional / Preference Cookies）
此类别旨在提升用户体验的"个性化记忆"，它们允许网站记住用户的选择和自定义设置。例如：
界面偏好：记住用户选择的深色/浅色模式、字体大小、页面布局等。
本地化设置：保存用户选择的语言、国家/地区、货币单位等，避免每次访问都要重新设置。
多媒体与交互：例如记住视频播放器上次播放的进度，或保存用户在评论区输入的昵称。
由于涉及收集用户的个人偏好数据，通常需要事先获得用户的明确同意（Opt-in）。如果用户拒绝，网站仍应可用，但可能无法提供这些个性化便利。
生命周期特点：通常为持久性 Cookie（Persistent Cookie），会设定一个较长的过期时间（如：几个月或一年），以便用户下次访问时依然生效。
3）追踪 Cookie（Tracking / Marketing / Analytics Cookies）
此类别是商业变现与数据洞察的"探针"，主要用于分析用户行为、衡量广告效果或进行精准营销。
常见的分析方法有三种：
数据分析（Analytics）：收集匿名或半匿名的统计数据，如页面访问量、停留时间、跳出率、用户点击热力图等，帮助网站优化内容和结构（如：Google Analytics）。
广告定向（Targeting/Advertising）：记录用户的浏览历史和兴趣标签，构建用户画像，从而在用户访问其他网站时推送高度相关的个性化广告。
归因分析（Attribution）：追踪用户是从哪个广告链接点击进入的，帮助广告主评估营销活动的投资回报率（ROI）。
传统的追踪 Cookie 多为第三方 Cookie （由广告网络或分析平台而非当前访问的网站设置）。随着隐私意识的觉醒和浏览器政策的变化（如：Safari 和 Firefox 已默认拦截，Chrome 正在逐步淘汰第三方 Cookie），这类 Cookie 的生存空间正在被大幅压缩 ，行业正逐渐转向隐私沙盒（Privacy Sandbox）等新技术。
**追踪 Cookie 是隐私监管最严格的领域。**包括浏览器在内的工具，必须通过醒目的 Cookie 弹窗获取用户的明确同意，且必须提供与"同意"同等便捷的"拒绝"选项。用户有权随时撤回同意并清除相关数据。
在实际的网站开发或隐私合规审查中，建议对这三类 Cookie 实行严格的分级管理：非必要不收集，收集必告知，追踪必授权。这不仅是法律合规的要求，也是建立用户信任、提升品牌声誉的关键。
1.3 按来源可以分两类：第一方、第三方
第一方 Cookie 就像是"店铺的私人助理"，只在本店为您服务，提升您的购物体验；而第三方 Cookie 则像是"尾随的陌生人"，跟着您穿梭于各个店铺，记录您的喜好并试图向您推销商品。
1）第一方 Cookie（First-Party Cookies）
此类 Cookie 指的是由用户当前正在访问的网站（即浏览器地址栏中显示的域名）直接创建和读取的数据文件。
主要用途是服务于网站的核心功能与用户体验。例如：保持用户的登录状态，无需在每次跳转页面时重新验证；保存电商购物车中的商品；记住用户的语言、主题偏好或界面设置。
第一方 Cookie 的数据仅在用户与当前网站之间传输，不会与其他网站共享，因此通常不被视为侵入式跟踪。
所有主流浏览器均默认允许第一方 Cookie 的运行，它们是维持现代互联网基础体验的必要技术。
2）第三方 Cookie（Third-Party Cookies）
由当前访问的网站域名之外的第三方 （如：广告商、社交媒体插件、数据分析平台）**设置的 Cookie。**它们通常通过网页中嵌入的外部资源（如：<iframe>、广告横幅、追踪脚本）植入用户的设备。
主要用途：跨站追踪与商业变现。
构建用户画像：当用户访问多个嵌有同一第三方广告代码的网站时，该第三方可以读取并合并这些 Cookie，从而拼凑出用户的完整浏览历史、兴趣偏好和个人档案 。
精准定向广告：基于收集到的跨站行为数据，广告商可以在不同的网站上向用户推送高度个性化的广告（例如：在 A 网站搜索了手机，在 B 网站的社交媒体上就会看到手机广告）。
第三方 Cookie 往往在用户不知情或未明确同意的情况下，持续追踪用户的网络行为，这引发了极大的隐私担忧，甚至被用于实施身份盗窃或欺诈。
GDPR（通用数据保护条例）和 CCPA（加州消费者隐私法案）等法规要求，使用此类 Cookie 必须获得用户的明确同意，并允许用户查看或删除相关数据。
3）行业趋势：第三方 Cookie 的终结与替代
由于严重的隐私问题，整个互联网行业正在经历一场"去第三方 Cookie"的变革：
浏览器拦截：苹果的 Safari 和 Mozilla 的 Firefox 浏览器早已默认阻止或严格限制第三方 Cookie 的跨站追踪行为。
Chrome 的政策转向：谷歌曾计划在 Chrome 浏览器中逐步淘汰第三方 Cookie，并推出了"隐私沙盒（Privacy Sandbox）"计划作为替代方案（旨在通过聚合用户兴趣群组而非追踪个体来实现广告投放）。但受限于反垄断调查及行业阻力，谷歌在 2025 年宣布终止该淘汰计划，维持现状。
尽管第三方 Cookie 的消亡进程有所波折，但行业向"隐私优先"转型的趋势不可逆转。企业正越来越多地转向依赖第一方数据、情境智能广告（Contextual Advertising）以及统一身份识别方案（如：UID2.0）来替代传统的第三方追踪。
1.4 典型应用场景
1）会话管理
用户登录状态维持： 服务器生成唯一 SessionID 存入 Cookie，后续请求通过该 ID 识别用户，避免重复登录。
**购物车数据保存：**电商网站利用 Cookie 临时存储未结算商品，即使关闭页面后重新打开仍可恢复。
2）个性化服务
偏好设置记忆： 自动应用用户选择的语言、字体大小等，减少重复配置。
**内容定制：**根据历史行为推送相关内容（如：新闻推荐），提升用户体验。
3）行为分析与广告
流量统计： 匿名记录访问路径、停留时长等，优化网站设计（如 Google Analytics）。
**精准营销：**基于浏览记录投放相关广告，实现跨站追踪（需用户同意）。
1.5 与其他缓存的区别
| 特性 | Cookie | LocalStorage/SessionStorage |
|---|---|---|
| 存储容量 | ≤4KB | ≥5MB |
| 自动随请求发送 | 是（同域请求自动附加） | 否 |
| 生命周期控制 | 由服务器设置过期时间 | 需手动清除或依赖会话 |
| 主要用途 | 会话管理、身份识别 | 大容量数据缓存 |
二、什么是 Private state tokens？
2.1 简介
Private State Tokens（私有状态令牌，简称 PST）并非传统意义上的浏览器缓存类型，而是一种隐私保护技术，用于在不泄露用户身份的前提下验证用户行为真实性（如：区分真人与机器人）。它不用于存储网页资源或会话数据，而是通过加密令牌机制解决跨站跟踪与隐私泄露问题。
隐私优先的身份验证：PST 允许网站向用户发放匿名化验证令牌，证明用户是"合法访问者"，但不暴露具体身份信息，避免传统 Cookie 跨站追踪问题。
非缓存机制：与 Cookie、LocalStorage 等存储技术不同，PST 不用于缓存网页资源或用户数据，而是专注于安全验证流程，属于浏览器隐私沙箱的一部分。
PST 不是浏览器缓存技术，而是一种隐私优先的匿名验证协议，核心价值在于平衡安全验证与用户隐私**。开发者无法将其用作数据存储方案** ，其适用场景严格限定于反欺诈、广告验证等特定领域，且目前处于早期实验阶段。若需实现常规缓存功能，仍应优先使用 Cache-Control、Service Worker 等标准机制。
与传统缓存的关键区别：
| 特性 | Private State Tokens | 传统浏览器缓存（如 Cookie） |
|---|---|---|
| 主要用途 | 匿名验证用户真实性 | 存储会话状态、资源副本或用户偏好 |
| 数据可见性 | 完全加密，开发者无法直接读取内容 | 可被服务器或 JavaScript 读取 |
| 存储目的 | 防机器人/反欺诈，非资源复用 | 加速页面加载或维持会话状态 |
2.2 令牌生成与验证流程
**1）发行方（Issuer）签发：**受信任的第三方（如广告平台、安全服务）通过浏览器隐私沙箱生成加密令牌，仅包含"用户已通过验证"的证明，无具体身份信息。
**2）用户端存储与使用：**浏览器将令牌安全存储在隔离的隐私沙箱中，当用户访问合作网站时，自动提供验证证明，无需跨站传递用户标识。
**3）匿名化验证：**网站通过浏览器 API 验证令牌有效性，但无法获知用户身份或行为轨迹，实现"证明合法性而不泄露隐私"。
2.3 关键技术依赖
浏览器隐私沙箱：令牌生成、存储和验证均在浏览器受控环境中完成，开发者无法直接访问原始数据。
JavaScript API 交互：通过 navigator.privateStateToken.exchange() 触发验证流程，但返回的 token 是不透明的加密 Blob，无法被解析或篡改。
2.4 典型应用场景
1）反机器人与广告验证
广告欺诈防护： 广告平台通过 PST 证明用户是真人，避免机器人刷量，同时不收集跨站浏览历史。
无验证码验证： 替代传统 CAPTCHA，用户无需手动验证即可通过 PST 证明"非自动化流量"。
2）隐私合规的跨站交互
替代第三方 Cookie： 在 Safari、Firefox 逐步禁用第三方 Cookie 的背景下，PST 提供符合 GDPR/CCPA 的跨服务验证方案，仅传递"验证通过"信号，不共享用户标识。
**安全登录辅助：**与 OAuth 等协议结合，在敏感操作（如：支付）中追加匿名化真人验证，降低欺诈风险。
2.5 现状
浏览器支持有限，仅 Chrome 125+ 原生支持，且需手动启用实验性 Flag（--enable-features=PrivateStateTokens）。
严格环境要求：**必须运行在 HTTPS 或 localhost 环境。**发行方域名需预注册至浏览器白名单（由 Chrome 团队管理，不可自定义）。
开发者控制权弱：令牌内容由浏览器生成，开发者无法自定义数据结构，仅能触发验证流程。
当前还处于早期标准化阶段，因为由 Cloudflare 联合 Chrome、Firefox、Edge 推动成为行业标准，尚未广泛落地。
PST 还是非通用存储方案，不可用于常规数据缓存（如：页面资源、用户偏好），仅适用于特定验证场景。
- 为何常被误认为"缓存类型"？
首先是术语混淆。"Tokens"一词易被误解为可存储数据的载体，但PST 不提供开发者可读写的存储空间。
另外，部分浏览器开发者工具将 PST 归入"存储"标签页（如：Chrome 的 Application > Storage），但其本质是验证协议而非存储机制。
实际上，PST 属于隐私保护层，而非缓存层。PST 是浏览器隐私计算架构的一部分，目标是消除跨站追踪，而非优化资源加载速度。
仅在极少数情况下，PST 验证结果可能间接影响缓存策略（如：真人用户优先使用 CDN 缓存），但二者无直接技术关联。
三、两者的区别和联系
3.1 区别
Cookies 是开发者可控的传统会话标识工具，而 Private State Tokens 是浏览器自动管理的隐私保护协议。
二者均用于身份验证，但 PST 通过加密匿名化设计替代第三方 Cookie 的跨站追踪能力，不存储用户数据，开发者无法直接操作，仅用于防欺诈验证。
| 特性 | Cookies | Private State Tokens |
|---|---|---|
| 存储内容 | 明文键值对（如 user_id=123） |
加密令牌，无用户标识信息 |
| 隐私风险 | 高（易被跨站追踪，需 SameSite 防护） |
极低（设计即防追踪） |
| 开发者访问 | 可读写（document.cookie） |
完全不可见，仅浏览器内部使用 |
技术控制权方面：
Cookies：由服务器通过 Set-Cookie 头下发，开发者可自定义生命周期（Expires/Max-Age），需手动集成到业务逻辑（如：登录后写入 sessionID） 。
Private State Tokens：**浏览器自动管理，开发者无法直接操作。**仅通过 API 触发验证流程（如：调用 navigator.privateAggregation.reportEvent），令牌生成与验证完全由浏览器控制。
核心用途方面也不同：
Cookies：维持用户级会话状态 （如：登录态、购物车）。依赖服务器存储 Session 数据完成身份验证。
Private State Tokens：解决跨站欺诈问题（如：反机器人验证），不用于用户身份识别。在用户访问广告或登录页面时，匿名证明"该用户是真人"，避免暴露身份信息。
3.2 相同点
1）共同目标：验证用户真实性
二者均服务于身份验证场景，但解决的问题层次不同：
Cookies 验证"这是哪个用户"（需关联服务器 Session）。
PST 验证"该用户行为是否可信"（如：是否为真人操作），不涉及具体身份。
2）PST 是 Cookie 在隐私时代的演进
替代第三方 Cookie 的追踪功能：PST 通过加密协议实现跨站反欺诈验证（如：广告点击验证），无需共享用户标识，直接规避 GDPR/CCPA 合规风险。
互补而非取代：一方 Cookie 仍用于常规会话管理（如：登录态）。
PST 仅用于特定隐私敏感场景（如：广告验证），二者可共存。
3）技术协同场景
广告反欺诈验证流程：
用户点击广告后，发布商通过 PST 向广告平台发送匿名验证请求。
浏览器自动用 PST 生成加密令牌，证明用户行为可信（而非暴露身份）。
广告平台验证令牌后计费，无需依赖第三方 Cookie 追踪用户。
四、小小的总结
Cookies 是"身份标识载体"，PST 是"匿名验证协议"------二者同属身份管理范畴，但 PST 通过隐私优先设计规避了 Cookie 的追踪缺陷。
PST 不存储数据、不可被开发者操控，仅用于特定反欺诈场景，无法替代 Cookies 的常规会话管理功能。
实际开发中：
用 Cookies + Token 机制处理用户登录。
用 PST 解决跨站隐私合规问题（如：广告验证），避免混淆二者定位。
何时使用 Cookies？
需要维持用户登录状态或存储少量会话数据时。
必须配置安全属性：HttpOnly（防 XSS 窃取）、Secure（仅 HTTPS 传输）、SameSite=Strict（防 CSRF）。
何时使用 Private State Tokens？
仅限特定场景：广告平台反欺诈验证，需符合 Privacy Sandbox 标准的跨站行为验证（如：Google Ads）。
无需主动集成：依赖浏览器自动触发，开发者仅需调用标准 API（如：privateAggregation）。