Playwright 登录态持久化两条路：storage_state 与 persistent profile 为何不通用

做浏览器自动化时，登录态持久化是绕不开的问题。Playwright 提供了两条路：storage_state 导出和 persistent profile。我一开始以为它们只是"同一个功能的两种写法"，直到上周踩了坑才发现，二者导出的会话并不通用。

一、两条路各自是什么

1. storage_state：登录成功后调 ctx.storage_state(path="xx.json")，把 Cookie 和 localStorage 快照存成 JSON。之后任何进程都可以用它 new_context(storage_state="xx.json") 恢复登录态。

2. persistent profile：launch_persistent_context(user_data_dir=xxx)，浏览器把所有数据（Cookie、缓存、指纹相关文件）写进一个目录，下次从同一目录启动，效果类似"继续用上次的浏览器"。

二、坑在哪里

我有个场景先用 persistent profile 完成了登录，想切换到更轻的 storage_state 方式跑后续任务，结果新会话直接被服务端判定未登录。反过来从 storage_state 起的会话去"接管"persistent 目录，也一样失败。

原因是两者的会话状态并不只是 Cookie 集合：persistent 目录里还有设备指纹、TLS 会话票据、本地存储的加密密钥等运行时状态；storage_state 只是快照了 Cookie 和 storage。对于校验较严的站点（风控会比对设备指纹与会话的绑定关系），从 persistent 目录"抽"出来的纯 Cookie 会话，指纹对不上，就会被判失效。

三、实践建议

1. 同一套任务从头到尾只用一种方式。要么全用 storage_state（轻、易管理、可多机分发），要么全用 persistent（重、但指纹一致性好）。

2. storage_state 的过期问题要单独处理：Cookie 有过期时间，长任务建议每次任务结束后重新导出，而不是依赖几天前的旧快照。

3. 遇到"明明有 Cookie 却提示未登录"，先检查是否混用了两种方式，再检查 Cookie 是否过期，最后才考虑风控。

4. 多账号场景用 storage_state 更省心：每个账号一个 JSON 文件，按需加载，不需要维护 N 个浏览器目录。

四、一个判断技巧

如果站点登录后访问关键接口时带了设备相关的自定义头（比如 X-Device-Id），基本可以断定它校验指纹绑定，这种站点优先选 persistent profile；如果只靠标准 Cookie 鉴权，storage_state 就够了。

总结：两条路没有绝对优劣，关键是"一条道走到黑"。混用是这类问题最常见的根源。