Cookie、本地存储、缓存与浏览器指纹有什么不同

这些概念经常一起出现在隐私设置、排错说明和配置文件产品中，但行为差异很大。因此，“清一下浏览器”并不是完整的操作说明。

先理解各自的作用

机制	谁创建或控制	通常范围	常见用途	是否自动随请求发送？
HTTP Cookie	服务器设置，浏览器按范围规则保存并回传	主机或域、路径、有效期与连接条件	会话标识、偏好、防滥用状态	请求匹配范围时会发送
localStorage	网站 JavaScript	源，并受浏览器分区和策略影响	持久化键值应用状态	不会
sessionStorage	网站 JavaScript	顶层浏览会话内的源	临时标签页或流程状态	不会
HTTP 缓存	浏览器与 HTTP 缓存规则	缓存键、响应指令、浏览器策略	重用响应，降低延迟与流量	可能直接满足请求，或重新验证
Cache Storage API	网站或 Service Worker 的 JavaScript	源或存储分区	离线资源和应用自行管理的响应	不会自动附加，由脚本决定如何使用
浏览器指纹	网站或其他观察者测量信号	取决于观察者与信号	安全、防欺诈、分析或追踪	部分信号出现在请求中，其余需主动执行代码

前五项涉及保留状态。最后一项是观察和关联方法，不过保留状态也可能成为其输入。

Cookie：按范围规则提供给服务器的状态

HTTP 本身大致无状态。Cookie 让服务器交给浏览器一组名称和值，并在之后匹配的请求中再次收到它。RFC 6265定义了响应中的 Set-Cookie、请求中的 Cookie 标头，以及浏览器存储模型。

Cookie 可以具备以下特性：

• 会话型： 保留到浏览器定义的会话结束。
• 持久型： 具有到期时间或最长存活时间。
• 仅主机： 只回传给设置它的主机。
• 域范围： 可发送给指定域与匹配子域。
• 路径范围： 只对匹配请求路径回传。
• Secure： 只通过浏览器定义的安全通道回传。
• HttpOnly： 不提供给脚本可访问的 Cookie API，但仍可用于 HTTP 请求。

这些属性影响传送与脚本访问，不会让 Cookie 值成为独立安全边界。RFC 6265 特别提醒，不应把 Path 依赖为安全机制，并建议对敏感 Cookie 内容采用安全传输和额外保护。

为什么删除 Cookie 会退出登录

很多服务在 Cookie 中保存随机会话标识，账号记录与会话详情留在服务器。删除 Cookie 移除了浏览器持有的标识，下一次请求就不再出示原会话。服务端账号与其他会话可能仍然存在。

这也解释了为什么复制验证 Cookie 很敏感：有效会话标识可能等同凭证。不要把原始 Cookie 粘贴到工单、日志、自动化输出或团队聊天。

本地存储：由脚本控制、属于特定源的状态

HTML 标准将 localStorage 定义为访问某个源的本地存储区域，设计用途是跨窗口使用并在当前会话之后保留。其中保存字符串键值对，具有该源访问权的脚本可以读取。

源通常由协议、主机和端口组成。因此以下属于不同存储范围：

• https://app.example.test
• http://app.example.test
• https://admin.example.test
• https://app.example.test:8443

网址路径不属于源。同一源下的 /billing/ 和 /support/ 可以访问相同本地存储区域，除非应用自行建立逻辑分隔。

与 Cookie 不同，localStorage 条目不会自动附加到 HTTP 请求。网站脚本必须读取并决定如何使用，因此适合界面偏好、草稿状态和应用数据。但任何以该源权限执行的脚本都可能读取它。敏感会话设计应考虑脚本被入侵，而不是假定“本地”就意味着“保密”。

这里的持久性意味着数据能跨浏览会话保留，不代表永久保存。用户可以清除，浏览器策略可以限制，存储容量与逐出规则也可能影响保留。

sessionStorage 的存活时间不同

sessionStorage 与源及顶层浏览会话关联，适合在标签页或窗口流程持续期间保留、随后随会话结束的状态。复制或恢复标签页可能涉及浏览器特有的生命周期细节，因此不能把它作为重要工作的唯一记录。

本地存储只是网站数据机制之一

现代网页应用还可能把数据放进 IndexedDB、Cache Storage、Service Worker 注册、源私有文件系统、权限和其他浏览器管理的存储。只在开发者工具中清除 localStorage，可能留下其他状态。

HTML 标准的隐私指导建议让用户一起清除持久化存储机制，否则网站可能用一个存储区重建从另一存储区移除的标识。

“缓存”包含多种机制

HTTP 缓存

RFC 9111将 HTTP 缓存定义为响应消息存储，以及控制存储、获取和删除的系统。浏览器可重用仍新鲜的响应，或重新验证已过期响应，减少延迟和网络传输。

缓存键至少包含请求方法与目标 URI，响应头影响能否重用及可用多久。HTTP 缓存是优化层。某张图片或脚本被缓存，通常不代表用户已经登录。

缓存状态仍可能影响隐私。在某些威胁模型中，加载耗时或资源是否已存在可能透露信息。W3C 指纹指南也把观察缓存资源列为推断浏览器或用户配置的方法之一。

Cache Storage 与 Service Worker

Cache Storage API 为网站提供明确、由脚本控制的 Cache 对象，常用于离线网页应用。Service Workers 规范说明，这些缓存与浏览器 HTTP 缓存分开、按源隔离，由应用逻辑更新和删除，而不是按普通 HTTP 新鲜度规则处理。

排错时需要区分：

• 清除“缓存的图片和文件”针对浏览器普通缓存。
• 清除网站数据也可能移除 Cache Storage 与 Service Worker 状态。
• 重新加载时跳过 HTTP 缓存，仍可能有活动 Service Worker 控制请求。

决定如何检查或清除前，先说清是哪种缓存。

存储分区增加另一个判断条件

过去，按源划分范围可能让嵌入的第三方，在多个顶层网站中读取同一份存储。现代浏览器越来越多地把顶层网站或相关环境加入存储键。

Chrome 的存储分区说明指出，嵌在 a.com 中的 example.com 框架，不会自动与嵌在 b.com 中的同源框架共享 Local Storage、IndexedDB、Cache Storage、Service Worker 及部分通信机制。Chrome 表示，该功能自 Chrome 115 起已对所有用户启用，另一些 API 在后续版本有所调整。

因此，同一个嵌入源可能因外层网站不同而看到不同存储。但这不代表所有存储都有统一的双键模型。浏览器版本、顶层与嵌入环境、存储访问授权、企业策略、扩展与各 API 规则，都可能改变结果。

应测试确切环境，不要仅凭域名推断。

浏览器指纹是观察到的信号，不是一个文件夹

W3C 将浏览器指纹识别定义为：通过配置或其他可观察特征，识别或再次识别用户、用户代理或设备的能力。其 2025 年指南区分几种形式：

• 被动指纹识别： 使用请求或网络中已可见的信息，例如请求头与 IP。
• 主动指纹识别： 执行代码，观察窗口大小、字体、连接设备、性能、传感器或图形渲染。
• 短暂事件关联： 通过几乎同时发生的设备或环境变化关联不同上下文。
• 类似 Cookie 的技术： 利用可能比 Cookie 保留更久、或能重建 Cookie 的机制保存和读取状态。

指纹很少是浏览器保存的某个不可变值。观察者选择信号、组合它们，再判断与此前访问有多相似。浏览器更新、窗口变化、增加字体、连接设备或网络路由改变时，结果可能改变。清除 Cookie 后也可能仍相似，因为很多底层信号未变。

指纹不是身份的证明

一组信号可能为许多人共有，同一个人的信号也可能漂移。网站还可能把指纹与登录、服务端账号历史、网络信誉或存储标识结合。因此，清除数据后仍被认出，不能证明只有指纹识别发挥了作用。

同理，改变一个可见设置不能保证新身份。协调且常见的配置可能降低部分独特性，而大量不寻常的独立修改可能形成更罕见组合。这些信号不能支持“隐形”或“第三方一定接受”的保证。

常见清除操作实际改变什么

操作	可能效果	重要残留
删除某网站 Cookie	移除匹配的浏览器 Cookie 状态，通常使该配置文件退出登录	服务端账号、其他设备和非 Cookie 存储可能仍在
删除 Cookie 和其他网站数据	依界面与范围，可能移除 Cookie、Web Storage、IndexedDB、Service Worker 等	密码管理器、下载文件、账号端数据与设备信号是独立项目
删除缓存图片和文件	移除普通缓存响应内容	Cookie、本地存储与 Cache Storage 可能需另选
清除历史记录	移除所选范围的访问网址与相关建议	已下载文件与网站记录仍在
删除浏览器配置文件	从设备移除该配置文件的本地书签、历史、密码与设置	同步账号数据、下载或导出、备份及服务端数据可能仍在
新建配置文件	从另一组配置文件状态开始	设备、操作系统、浏览器构建与网络仍可能被关联

Chrome 的浏览数据指南分别列出历史、Cookie 与网站数据、缓存图片和文件、下载记录、自动填充、网站设置及托管应用数据。它也说明，删除下载记录不会删除电脑上的文件；在登录状态下删除数据，可能影响 Google 账号及其他同步设备。

具体效果取决于时间范围、配置文件、账号状态、浏览器版本和企业策略。删除难以恢复的数据前，应阅读确认说明。

独立配置文件如何影响各项机制

正确分隔的持久化配置文件，应各自拥有 Cookie 存储、网页存储、网站数据库、Cache Storage、HTTP 缓存、历史、网站权限和扩展状态，避免 B 直接继承 A 的已保存会话。

但以下信号可能仍相同：

• 浏览器引擎与版本。
• 操作系统和硬件。
• 系统字体与显示特征。
• 从主机继承的语言、时区或无障碍设置。
• 未配置独立路由时的 IP 和网络路径。
• 在应用层关联活动的操作行为或登录。

扩展、权限、窗口大小、语言设置和代理路由，也可能让不同配置文件呈现不同信号。最终效果取决于实现与场景。应把配置文件分隔评估为状态隔离，而不是指纹保证。

先诊断症状，再清除全部数据

“我退出登录了”

先查 Cookie。会话 Cookie 可能过期、被删除、被浏览器策略拒绝，或被服务器撤销。本地存储可以支持界面，但通常不是自动随 HTTP 请求发送、用于身份验证的 Cookie。

“网站忘了草稿或离线数据”

检查本地存储、IndexedDB、Cache Storage 和 Service Worker。确认源，以及页面处于顶层还是嵌入其他网站，因为分区可能改变可用存储。

“第一次重新加载很慢”

空的或过期 HTTP 缓存可能是因素。网络、服务器和 Service Worker 也可能造成同样表现，因此先记录请求时间与缓存状态再判断。

“清除数据后，网站仍认识这个环境”

可能原因包括：账号仍在别处登录、服务器通过账号或网络信息关联访问、其他浏览器存储幸存，或可观察特征关联了会话。指纹识别是一个假设，不是自动成立的答案。

按机制选择处理方法

• 涉及服务端会话时，检查或清除 Cookie。
• 网页应用保留本地状态时，检查按源划分的网站存储。
• 排查过期或离线内容时，区分 HTTP 缓存与 Cache Storage。
• 工作状态必须独立时，使用独立持久化配置文件。
• 将指纹识别视为对可观察信号的关联；清除数据或更改单项设置，无法消除所有识别依据。

这能避免两种高成本错误：删除超过必要范围的状态，以及以为空 Cookie 存储就创造了新设备身份。

适用限制

Web 存储与隐私行为随浏览器和版本演进。第三方 Cookie 规则、存储分区、数据逐出、同步、企业策略、扩展与私密浏览模式，都可能改变本文行为。本指南解释查阅日期时的标准和 Chrome 文档，不覆盖所有浏览器或网站实现。