Cookie 还在，为什么登录态还是异常？

做多账号环境排查时，经常会遇到一种情况：Cookie 文件还在，页面也没有完全退出登录，但账号状态就是不对。

比如：

- 打开后台后进入了旧账号。

- 页面显示已登录，但关键接口返回未授权。

- 脚本读取到 Cookie，却无法恢复上次任务状态。

- 换一台机器或换一个 Profile 后，登录态表现不一致。

这时不要只盯 Cookie。Cookie 是登录态的一部分，但不是完整账号环境。

1. 先确认 Cookie 属于哪个 Profile

第一步不是看 Cookie 数量，而是确认它属于哪个浏览器 Profile。

至少记录这几个字段：

profile_id:
account_id:
site:
cookie_source:
last_login_time:
last_used_task:

如果 Cookie 是从旧环境复制来的，但当前 Profile 的本地存储、扩展状态、语言、时区和代理都变了，页面可能会出现半登录状态。

常见表现是首页看起来登录成功，但进入二级页面、提交表单或读取接口时失败。

2. 再看 LocalStorage 和 IndexedDB

很多站点不只靠 Cookie 保存状态。

它们还会把页面配置、用户偏好、工作台状态、临时 token、最近打开项目放在 LocalStorage、SessionStorage 或 IndexedDB 里。

排查时可以分三步：

1. 检查 Cookie 是否存在关键站点域名。
2. 检查 LocalStorage 是否有账号、组织、租户、语言等字段。
3. 检查 IndexedDB 或缓存里是否保存了旧任务状态。

如果 Cookie 是新的，但 LocalStorage 里还残留旧账号信息，页面可能进入错乱状态。反过来，如果 Cookie 还在，但本地存储被清掉，页面也可能要求重新验证。

3. 区分“登录成功”和“业务状态可用”

很多脚本只判断一个条件：

has_cookie == true

这个判断太粗。

更稳的做法是把登录态拆成几层：

cookie_exists: true/false
session_valid: true/false
account_matched: true/false
permission_ok: true/false
business_page_ready: true/false

只有 Cookie 存在，不代表 session 仍然有效。session 有效，也不代表当前账号和任务目标一致。账号一致，也不代表当前权限能执行后续步骤。

所以自动化任务不要只写“检测到 Cookie 就继续”。至少要确认账号名、组织名、当前 URL、关键元素和权限状态。

4. 检查代理、时区和语言有没有一起变

登录态异常有时不是 Cookie 自身问题，而是环境信号变化太大。

排查顺序可以这样走：

Profile 是否变化
Cookie 是否来自同一账号
LocalStorage 是否残留旧状态
代理出口是否变化
浏览器语言是否变化
时区是否变化
任务入口 URL 是否变化

如果同时换了 Profile、代理和语言，再去判断“Cookie 为什么失效”，基本很难定位。应该一次只改一个变量，并记录改动前后的状态。

5. 给任务日志补几个字段

为了避免下次继续猜，可以让任务日志多记录这些字段：

task_id:
profile_id:
account_expected:
account_detected:
proxy_id:
timezone:
language:
cookie_check:
storage_check:
final_url:
permission_check:
failure_reason:

有了这些字段，排查时就能判断问题发生在哪一层：Cookie 层、存储层、Profile 层、代理层，还是权限层。

如果团队已经在用 AI Agent、Playwright 或无头任务处理多账号流程，可以参考这种先确认 Profile、Cookie、代理和任务边界是否被拆开的思路。它更适合用来做排查顺序参考，而不是把 Cookie 当成唯一判断依据。

结论

Cookie 还在，不等于登录态一定可用。

排查时先确认 Cookie 属于哪个 Profile，再检查 LocalStorage、Session、代理、语言、时区和任务目标。对自动化任务来说，真正可靠的不是“有 Cookie”，而是能确认当前账号、当前环境和当前任务是同一套上下文。