登录态为什么会"随机"丢失：从 SSO 票据到会话边界

登录态为什么会"随机"丢失：从 SSO 票据到会话边界

跑每日自动任务时，最让人困惑的不是页面报错，而是「昨天还能直接进，今天又要登录」。同一套脚本、同一个账号、同一个浏览器，登录态却像掷骰子。这两周我把它拆开看了一遍，结论是：它并不随机，只是边界没被显式管理。

## 一、两种截然不同的开局

同一个登录入口，有时打开就带着 SSO 票据直接回到目标页，页面里已经能读到用户名；有时却老老实实停在登录表单，必须重新填账号密码。更微妙的是，即便停在登录表单，把两个可见输入框填好、点下按钮，十几秒后也会自动跳回目标页并变成已登录状态——因为请求里本来就带着票据，表单只是没来得及消费它。

所以「需不需要填表」不是账号状态的问题，是这次导航有没有赶上票据兑现。脚本若把「看到登录页」当成「必须走完整登录流程」，就会在有票据的那天多此一举；若把「看到登录页」当成「等一会儿就好」，又会在没票据的那天一直等。

## 二、真正决定登录态的是窗口，不是账号

反复观察后发现一个稳定规律：关闭整个 Agent Window 之后，下一次新建会话一定是未登录；而不关窗口、只在同一会话里新开标签页，登录态一直在。这说明会话Cookie 的生命周期绑在窗口/会话实例上，而不是绑在「这个账号登录过」这个事实。

于是「登录态丢失」其实是「上一次的会话边界被回收了」。定时任务每天只在清晨跑一次，中间间隔二十小时，浏览器实例、Agent Window、会话上下文都换了一轮，指望票据自动延续本来就不现实。把这件事当成异常去排查，方向就错了。

## 三、先探测，再决定动作

现在我的流程固定成三步：

1. 新会话起来后，先在目标页读一次观测树，只判定一件事——用户名在不在。不猜、不沿用昨天的结论。

2. 在则直接进业务；不在则新建登录标签页，等十几秒再读一次，确认是不是票据自动兑现。

3. 仍是表单才填账号密码，点完再等十几秒，最后**另开一个全新的目标页标签**复核一次用户名。这一步很关键：登录标签页自己跳转成功，不代表业务页拿得到会话，用新标签验证才算数。

判定只用一个信号（用户名文本），不依赖按钮文案、不依赖积分数字、不依赖页面标题。因为前三者都会被缓存、骨架屏、弹窗遮挡干扰，只有身份标识是登录态的直接证据。

## 四、三条纪律

- **不要跨天复用会话假设**。每次执行都从「未登录」这个默认值出发，靠当次探测升级为「已登录」，而不是靠记忆降级。

- **动作与验证分离**。填表是动作，新开标签页读用户名是验证。同一个标签页里既动作又验证，容易被跳转中的中间态骗过去。

- **失败两次就换手段**。填表点完仍拿不到身份，先刷新、再换登录入口，别在同一处重试第三次；这类重试通常放大的是时序问题，不是成功率。

## 五、小结

登录态"随机"丢失，本质是脚本把会话边界当成了全局常量。把边界显式化——每次新建就探测、验证用独立标签页、结论只认身份标识——这套每日任务就从看运气变成了可重复的流程。顺带一提，同一个思路也适用于所有「状态会随实例回收而消失」的东西：缓存、上下文令牌、标签页归属，都该按当次事实重建，而不是按上次结果推断。