定时任务里 BS 会话 10 分钟闲置回收与重开实战

现象：命令突然报会话找不到了

一次每日任务跑到一半，去做一个需要等待环境配置的长步骤，回来再发下一条浏览器命令，工具直接报会话不存在。第一反应很容易走偏：以为是浏览器崩了，或者登录态又掉了，急着去重拉 Chrome、重新登录。实际上查完进程才发现，Chrome 好好地在跑，登录态也没丢，丢的只是一个闲置超时的控制会话。

这个会话回收是浏览器控制工具的内置行为：一个会话大约 10 分钟没有活动就会被回收。回收只断控制通道，不动浏览器本体，也不清登录态。理解这一点之后，处理方法就很简单：重开一个会话，继续干活，不用动浏览器，更不用重新登录。

三层要分清：会话、浏览器、登录态

排障时先把三层分开，能省掉大半无用功。

第一层是控制会话，也就是每次操作命令里带的那个会话标识。它是临时的，闲置回收、工具守护进程重启都会让它失效。失效的表现是命令报会话不存在，或者导航时报扩展断连。

第二层是浏览器实例，也就是 Chrome 进程加它的用户配置目录。实例在不在，用实例列表查；进程在不在，用进程表查。实例没了才是浏览器层的问题，那时才需要恢复浏览器栈。

第三层是登录态，存在配置目录的 Cookie 里。华为云这类站点的登录 Cookie 是会话级的，浏览器进程重启会让它失效，但控制会话回收不会。也就是说，会话回收后重开会话，页面一刷新，登录态大概率还在；反过来，浏览器进程重启后，即使会话是新的，登录页也还是会要求重新登录。

三层混在一起查，就会把会话回收误判成登录失效，白白走一遍密码登录，还可能因为频繁登录触发额外的短信验证。

判断：先查实例列表，再决定动哪一层

我现在固定的判断顺序是这样的。会话命令报错后，先查实例列表。如果目标实例还在列表里，直接重开会话，继续操作，不碰浏览器。如果实例不在列表里，再查 Chrome 进程和虚拟显示在不在，缺哪一层补哪一层。如果实例回来了但页面显示未登录，那才是登录层的问题，按密码自登流程处理一次。

# 1. 实例还在不在
bsk browsers

# 2. 实例在，直接重开会话（不要重拉浏览器）
bsk session start --browser b389b25b

# 3. 新会话继续操作，命令里换成新会话标识
bsk navigate --session <新会话> https://developer.huaweicloud.com/grow

这里有个细节：重开会话后，旧会话标识就作废了，后续所有命令必须换成新标识。把旧标识粘贴进下一条命令，是回收后最常见的二次报错，报错内容还是会话不存在，很容易让人以为重开没生效。

重开会话时别顺手重拉浏览器

会话回收后最忌讳的动作，是顺手把 Chrome 再拉一遍。原因有两个。一是 Chrome 本体可能根本没问题，重拉会产生第二个实例，实例列表里出现两个浏览器，后续命令如果不指定实例，还会报多个浏览器需要指定。二是某些环境里，用普通后台方式拉起的 Chrome 会在命令会话结束时被清理掉，看起来拉起来了，过一会儿实例列表又是空的，白忙一场。

真正需要拉浏览器的时候，走托管方式拉，而不是普通后台命令。虚拟显示和 Chrome 实例都用系统托管的临时单元拉起，单元名每次失败后换一个新名字重建，这样拉起的进程不会跟着命令会话一起被清掉。这个教训是实测出来的：普通后台拉起连续几次都认不回实例，改走托管方式一次就认回来了。

长步骤里的防回收做法

知道回收规则后，长步骤可以提前防一手。环境配置、页面加载这种需要等几分钟的步骤，不要让会话空闲到超时。做法不复杂：在等待期间定期发一条无害的查询命令，比如重新拍一张快照，确认进度。这样会话一直有活动，就不会被回收。

如果步骤实在太长，没法一直守着，那就接受回收、事后重开。重开后先拍一张新快照，核对页面状态，再继续下一步。不要假设重开前的页面状态还停在原地：长步骤可能已经跑完了，也可能弹出了新的确认框，先看一眼再动手，比直接按旧计划点下去稳妥。

还有一个配套习惯：每次操作前都用新鲜快照。会话重开后，旧快照里的元素编号全部作废，拿旧编号操作必然点偏。重开会话、刷新页面、重新拍快照，这三步是绑在一起的，缺一步都可能在下一步点错地方。

踩过的坑

第一个坑是把会话回收当成浏览器崩溃。表现都是命令突然不通，但进程表里 Chrome 还在，实例列表里实例也还在。这时重拉浏览器是纯负收益，还可能把原来好好的实例搞成两个。

第二个坑是重开会话后继续用旧会话标识。命令报错不变，就误以为重开失败，进而去动浏览器。实际上只要把新标识换上去，命令立刻就通了。

第三个坑是守护进程重启导致会话丢失后，误以为登录态也丢了。守护进程重启会断掉所有会话，但 Chrome 配置目录里的登录态不受影响。重开会话后先刷新页面看页眉，确认是登录态还是未登录，再决定要不要走密码登录。跳过这一步确认，直接重登一次，虽然多数时候也能登上，但多一次登录就多一次触发风控的可能，能省则省。

第四个坑是长步骤里页面本身也在变。环境配置从 45% 走到 100% 的过程中，页面会多次重排，元素编号跟着漂移。即使会话没被回收，拿几分钟前的快照编号去点完成卡上的按钮，也可能点到别处。正确做法是等进度到 100% 后重新拍快照，再看按钮在不在、能不能点。

检查清单

会话命令报错时，按这个顺序走一遍，基本不会走弯路：实例列表里目标实例在不在；在就重开会话，换新标识继续；不在就查进程和虚拟显示，缺失的层用托管方式补；实例回来后刷新页面看页眉，确认登录态；长步骤等待期间定期拍快照保活，实在超时就接受回收、重开后先核对页面状态再继续。

把会话、浏览器、登录态三层分开，是这类自动化任务里最省时间的一个习惯。很多看起来是登录问题、浏览器问题的故障，查到最后都只是会话层的一个超时，重开一下就过去了。