爬虫 Cookies：浏览器运行之间的状态连续性

下一次采集时 cookies 可能仍在，应用却认为登录已经结束。Cookie 存储、应用数据库和浏览器指纹配置文件代表不同状态。BotBrowser 文档介绍可复用指纹配置与隔离的浏览器上下文，但不保证访问，也不会恢复第三方登录。获授权的任务需要分别记录：哪些客户端状态跨过了声明的运行边界，以及应用是否接受了恢复后的请求。

摘要

• 先说明复用标签页、新建上下文还是重启进程，这些边界并不相同。
• 将 cookies、localStorage、IndexedDB 与 sessionStorage 按作用域和生命周期分别处理。
• Playwright 在受支持版本中显式启用后可包含 IndexedDB；sessionStorage 需要应用单独决定如何处理。
• BotBrowser 指纹配置不能代替浏览器数据目录或框架状态快照。
• 用自有 fixture 的无敏感标记检查连续性，诊断不含凭据，服务器接受结果另行记录。

目录

• 声明两次运行之间的边界
• 四种存储与四个连续性问题
• Cookie 存在不等于适用于请求
• 明确选择状态交接方式
• 自有源上的连续性预检
• 故障表现与未确认原因
• BotBrowser 身份与应用状态
• 实践结论

声明两次运行之间的边界

先命名生命周期操作。刷新现有标签页、打开独立标签页、新建浏览器上下文、重启浏览器进程是不同事件。调度器的运行标识不会自动定义这些事件。应把上下文选择与存储策略保留在任务配置中，便于区分刻意为空与意外丢失。若任务每次创建新上下文，再次启动同一可执行文件也不能证明状态持续存在。

例如，自有 fixture 可以在 localStorage 保存无敏感偏好，在 sessionStorage 保存临时流程标记。刷新与新上下文不是可互换的实验。前者可能保留页面会话，后者需要显式交接适用存储。这是建议的 fixture 设计，不是已经完成的浏览器测量。比较两种边界前，应预先声明每个存储的预期结果。

记录源与应用修订版。源包括协议、主机和端口，因此改变本地 fixture 端口就改变了存储问题。Cookies 遵循自己的主机／域及路径规则，不等于 localStorage 的同源划分。浏览器存储模型区分这些作用域。即使两个页面外观相同，在另一个源读取成功，也不是对原存储的观察。

同时声明下次任务允许复用什么。公开数据任务可能无需认证，自有应用测试可能使用专门测试账号，两者安全要求不同。不要仅因为工具支持导出，就保留账号会话。授权与服务协议必须允许复用，而且任务只应请求实际需要的状态。如果要求干净上下文，应将缺失记录为刻意设计。

四种存储与四个连续性问题

MDN Cookie 指南区分带到期时间的持久 cookie 和不带到期时间的会话 cookie。浏览器会话恢复可能恢复会话 cookie，因此仅重启浏览器不能断言它们全部消失。反过来，到期时间也不承诺值一定保存到那个时刻。保留、请求适用性与服务器有效性，不能压成一个“cookie 存在”标记。

MDN localStorage 参考说明按源划分、可跨浏览器会话保存且没有内建到期时间的存储。这不保证主动清除、切换存储上下文或结束隐私浏览后仍保留。应用还可以用自己的时间戳拒绝旧值。应检查声明的存储与应用规则，不能把没有内建到期等同于永久登录。

MDN sessionStorage 参考按源与顶层浏览上下文分开数据。它可以在页面会话内跨刷新保留，关闭标签页则结束会话。若存在 opener，新标签页可能先获得副本，但后续状态不是共享的实时存储。不能用这个例外承诺独立创建的新任务会继承旧标签页状态。

Playwright 的认证文档具体说明交接范围：可复用状态包含 cookies 与本地存储，IndexedDB 通过 indexedDB: true 启用，默认不包含。文档也说明会话存储属于标签页，该流程没有自动持久化它的接口。浏览器数据目录可能包含比框架快照更多的状态；应以文档规定的覆盖范围为准，而不是文件名。

存储	作用域与生命周期问题	跨运行检查
Cookies	适用哪个主机／域、路径、安全属性及到期条件？	适用元数据及自有服务器观察到的请求
localStorage	是否为同一个源与预定存储上下文？	在该源检查无敏感标记
IndexedDB	选定快照是否包含所需数据库状态？	确认受支持选项与应用标记
sessionStorage	同一页面会话，还是新标签页／上下文？	检查标签页标记，不假定自动快照覆盖

这张表是交接清单，不是完整序列化规范，也不覆盖全部浏览器存储或认证机制。Service worker 缓存、内存变量或应用持有的密钥，都可能形成额外依赖。如果所需状态不在四行之内，应明确依赖并使用其文档生命周期，而不是扩张 cookie 导出的含义来涵盖一切。

Cookie 存在不等于适用于请求

RFC 6265定义 HTTP 状态管理机制与 cookie 选择规则。只有名称和值会丢失重要作用域。仅主机 cookie 与域 cookie 不同，路径也可能排除当前请求。获授权的状态交接应保留这些属性，而不是把所有条目变成无限制名称／值对。服务器看到的是适用于该请求的 cookies，不是整个浏览器存储的转储。

Document.cookie 参考介绍面向页面的接口，不是通用凭据导出。HttpOnly cookie 无法通过页面 JavaScript 访问。因此，document.cookie 为空不能证明应用没有任何 cookies。获授权的元数据检查应使用框架文档规定的 cookie 接口，不要为了让诊断看起来完整而暴露 token 值。

Secure 与 SameSite 影响发送条件，所以即便存储没变，重定向或跨站请求也会改变问题。应保留相关顶层站点、目标和导航上下文，而不记录私密值。涉及分区或嵌入场景时，还应检查文档规定的分区上下文。复制 cookie 不保证它会随每个指向名称相似主机的请求发送。

Cookie 管理指南负责配置细节和属性处理。跨运行还需检查应用是否接受请求。服务器可独立于客户端存储使会话失效。保留的 cookie 可能引用已到期或撤销的服务器会话；公开页面接受访问，也不说明认证操作获许可。应保存授权任务实际需要的应用结果，而不只是 cookie 数量。

明确选择状态交接方式

BrowserContext storageState API规定框架快照。在兼容版本中，await context.storageState({ indexedDB: true }) 请求将 IndexedDB 与受支持状态一起保存。用这些状态创建的上下文，是收到文档规定数据的新上下文，不是旧标签页继续执行。快照不会自动恢复 sessionStorage、开放连接或任意 JavaScript 内存。

记录框架版本与选定选项。当前 API 文档里的选项，可能在旧安装中不存在。应明确解决兼容性问题，不能当作网站识别爬虫的证据。如果依赖 IndexedDB，先确认支持并启用，再依赖交接。还应在捕获前等待应用就绪：写入未完成时保存，可能准确保留一个不完整状态。

浏览器数据目录与框架快照的运行归属也不同。目录属于浏览器存储生命周期，不能随意共享给并发独立进程当作同步机制。应采用浏览器／框架支持的持久上下文设置。快照则是可以单独限定和核对的状态交接。两者都不构成混用账号状态，或把要求干净的上下文替换成其他账号目录的理由。

将保存状态视作敏感数据。Playwright 认证文档警告，浏览器状态文件可能使他人冒充账号，不应提交仓库。应使用应用中受访问控制的秘密管理流程，与博客证据、截图和普通任务日志分开。诊断应只包含存储是否存在、无敏感 fixture 标记及不透明引用，而不是真实 cookies、密码或账号完整存储内容。

自有源上的连续性预检

使用你控制的应用或 fixture。在可读 cookie、localStorage 和 sessionStorage 中放入无敏感 continuity-marker，若依赖数据库，再定义应用自己的 IndexedDB 标记。Cookie 使用合成值，不使用账号凭据。Fixture 应规定各次写入何时完成，以及选定边界后哪些状态应保留。若依赖 HttpOnly，必须由 fixture 服务器观察，页面 JavaScript 不能提供该观察。

下面的函数接收已经位于声明自有源的页面，只检查三个页面可读标记并返回布尔值。调用方提供无敏感标记并控制日志。它不会导航、创建或导出会话；源断言避免重定向后静默读取其他源。这只是检查器示例，不是已经记录的测试结果：

export async function checkReadableMarkers(page, ownedOrigin, marker) {
  return page.evaluate(
    ({ ownedOrigin, marker }) => {
      if (location.origin !== ownedOrigin) throw new Error('Origin mismatch');
      const cookies = document.cookie.split(';').map(value => value.trim());
      return {
        cookie: cookies.includes(`continuity-marker=${encodeURIComponent(marker)}`),
        local: localStorage.getItem('continuity-marker') === marker,
        tab: sessionStorage.getItem('continuity-marker') === marker,
      };
    },
    { ownedOrigin, marker }
  );
}

在同一声明边界两侧检查，保持 fixture 修订版与源相同。把观察时间、边界种类与布尔记录放在一起。IndexedDB 应在事务完成后通过 fixture 定义的读取检查；这个函数刻意不检查它。缺少数据库检查是明确覆盖缺口，不是隐含通过。不要添加可能把无关应用数据暴露到任务日志的通用数据库转储。

最后，由自有服务器确认自己的无害请求与所需应用结果，并和客户端标记记录分开。如果标记保留、服务器却拒绝操作，应调查其会话或授权记录。不要反复重试未获授权的请求，把标记保留变成成功结论。预检只验证 fixture 已声明的条件，不证明无关第三方会接受同一浏览器。

故障表现与未确认原因

若新上下文中所有源内标记都消失，先检查任务是否刻意从空状态开始，或是否加载预定状态工件。保留工件引用与上下文创建操作。若 localStorage 保留、标签页标记丢失，页面会话边界是应检查的具体差异。两者都不能识别浏览器指纹检测。应先将丢失存储对应到文档作用域，再改变无关设置或提高流量。爬虫分层诊断将状态交接不完整与已收到的 HTTP 拒绝、页面数据错误分别处理。

若 cookie 在允许的元数据检查中存在，却不在自有请求中，应检查目标、路径、安全属性、站点上下文及相关分区。若它随请求发送、应用却拒绝，则问题转向服务器有效性或授权。浏览器存在性检查无法确立这两点。将结果分开，操作人员才能仅用脱敏工件引用区分状态交接失败与无效会话。

若只在快照恢复后缺少数据，应检查捕获时机与文档覆盖范围。确认是否需要 IndexedDB、是否启用 indexedDB: true，以及应用写入是否完成。较晚的异步写入与漏掉整个存储，是不同故障表现。如果重定向改变源，应先记录路径变化，再解释本地存储为何为空。在错误源读取不到数据，不是对原始源数据丢失的测量。

预检应有界并考虑副作用。为检查会话连续性，应优先采用只读 fixture 条件，而不是真实购买、发消息或其他改变状态的操作。前提失败就停止并查看对应记录。没有获授权的服务器证据时，记录未知。清单的价值在于缩小下一步调查，不是虚构检测器结论或承诺账号持续可用。

BotBrowser 身份与应用状态

BotBrowser 配置文件管理区分可复用设备模型与 cookies 等会话设置。独立进程使用各自的数据目录；同一进程中的 BrowserContexts 则隔离存储与 cookies。因此，指纹包不是应用会话本身。复用同一个 --bot-profile 输入，不代表新上下文包含上次的 cookies 或 localStorage。

配置文件参考规定配置优先级与浏览器表面设置。应将指纹配置引用、有效覆盖项和框架状态策略作为不同任务输入。改变时区与数据库缺失是不同观察，不能互相替代。凭据不应放入共享配置包；应检查目标上下文存储，而不是通过熟悉的指纹报告推断它存在。

身份一致性可以描述配置意图，应用状态连续性描述特定数据是否保留，服务器接受则是第三个需要独立证据的问题。BotBrowser 不会让第三方会话永久存活，不授予访问权，也不保证恢复快照获接受。对于许可集成，可操作的结果是已知边界、核对必需存储，并独立确立应用结果。

常见问题

只有采集 cookies 就能恢复应用吗？

不一定。应用可能还依赖 localStorage 或 IndexedDB，服务器也能拒绝已保留会话。应声明必需状态并单独检查应用结果。

Playwright 状态快照包含 sessionStorage 吗？

文档规定的认证流程不会自动包含。它关联页面会话，应用特定交接需要另行决定并获得授权。

Cookie 存在却未使用，可能是什么原因？

作用域或安全属性可能排除该请求。即使已经发送，服务器有效性仍与客户端保留分开。

同一个 BotBrowser 配置会恢复之前的 cookies 吗？

不会。指纹包与应用存储职责不同。应采用预定上下文或持久数据生命周期，不能把指纹包当作账号快照。

来源

• MDN：Document.cookie
• MDN：HTTP cookies
• MDN：sessionStorage
• MDN：localStorage
• RFC 6265：HTTP 状态管理
• Playwright：认证
• Playwright：BrowserContext storageState
• Playwright：持久浏览器上下文
• BotBrowser：配置文件设置
• BotBrowser：配置文件管理
• 浏览器存储模型
• Cookie 管理

实践结论

先定义运行边界，再决定保留什么。在正确作用域检查每个必需存储，使用文档支持的交接，把账号秘密排除在诊断之外。指纹配置、客户端状态保留与服务器接受回答不同问题。只有任务所需状态和应用结果已经确立，才继续获授权工作；仅凭 cookie 存在并不够。