两个常驻浏览器跑了 12 小时，一个掉线一个还在：会话寿命到底由什么决定

为了每天自动签到，我让两个账号的浏览器页签一直开着不关，看能撑多久。两边条件几乎一致：同一台机器、同样的浏览器版本、同样的网络，都是扫码登录后停在后台。结果一个账号 12 小时后仍然在线，另一个中途掉回了登录页。

这篇不写教程，只把这个现象拆开看：同样是「不关页面」，为什么结局不一样。

一、页面没关，不代表会话还在

很多人把「浏览器窗口还开着」当成「登录还在」。其实页面活着的是一张已渲染的 DOM，登录有效性靠的是 Cookie 里的会话票据。页面可以一动不动地挂在那里，而票据早就被服务端判过期了——你看到的老界面只是个躯壳，一刷新就会跳回登录页。

所以测会话寿命不能用「窗口还在不在」当判据，得每次真的请求一次需要登录态的接口，看它是否还返回数据。我这一轮用的是成长中心的积分接口和登录状态接口，能拉到数据才算活着。

二、两个常见错觉

第一个错觉是「把 Cookie 存下来，下次加载就能续上」。把 Cookie 导出成文件、或者把整个浏览器用户目录拷走，本质是把票据复制了一份。票据本身在服务端有独立的有效期，复制它并不延长它。我试过保存整个用户数据目录，重启后依然要重新扫码。

第二个错觉是「会话 Cookie 一定写入磁盘」。不少站点的核心会话标识是会话级 Cookie，关掉最后一个进程就清掉，用户目录里根本不会留下这条记录。这类站点只有一条路：进程别停。

三、这一次分岔的三个可查方向

回到结果本身：两个账号的差别无非三种可能。

1) 服务端按账号给了不同的会话时长（新登录、异地登录、风险评分都会影响）
2) 两个页面里有一个被导航走了，票据在跳转中丢失
3) 浏览器进程本身被回收，会话级 Cookie 随进程一起消失

第三种最容易被忽略：进程没了，页面看起来还会「恢复」成上次的页面，于是你以为它一直在，其实是新进程重建的一模一样的界面，票据已经没了。我这次就是先确认进程还在、再确认票据还在，才知道是第 2 种。

四、想长期挂着，该盯什么

与其盯页面截图，不如盯三样东西：进程是否有独立心跳文件、登录态接口是否还返回数据、掉线后能否自动重新拉起并记录时间点。前两样是判断依据，第三样决定你第二天早上看到的是「还在」还是「昨晚两点就断了」。

最后一句实话：这类挂机保活没有一劳永逸的写法。会话能撑多久由服务端说了算，能不能续上由客户端说了算，能做的只是把「断了」这件事第一时间发现，而不是等第二天用的时候才发现已经断了。