怎么在比特浏览器里设置定时重启并保留登录状态？

功能定位：为什么需要「定时重启+会话保持」

在比特浏览器里同时开 50 个店铺环境时，Chromium 内存会随时间线性上涨；经验性观察，8 h 后单标签平均占用可多出 180–220 MB。定时重启能把内存压回基线，但重启后如果 Cookie、localStorage、IndexedDB 被清空，Amazon、Shopee 等平台会触发「新设备验证」，反而增加风控概率。因此，「定时重启」必须配套「会话保持」才安全。

功能定位：为什么需要「定时重启+会话保持」

版本差异与入口变更

截至当前的最新版本（v7.3.0）把「自动维护」从原来的「环境列表右上角 ⋮ 菜单」下沉到「分组右键→批量维护」。老用户如果找不到入口，请先把客户端更新至最新版，再按下方路径操作。

桌面端最短操作路径

1. 启动比特浏览器，进入「环境管理」页。
2. 在左侧树形分组上右键→批量维护→定时重启。
3. 在弹窗中勾选「重启后恢复登录状态」。
4. 设定周期：支持「每 N 小时」「每天固定时刻」两种粒度；建议首次测试用「每 6 小时」。
5. 「保留字段」默认勾 Cookie、localStorage、SessionStorage；如网站用 IndexedDB 记录登录，请手动追加。
6. 点击「生成计划」→「应用到全组」，客户端会在后台创建计划任务。

Mac 与 Windows 差异

Mac 版由于沙箱限制，定时重启依赖 launchd；首次配置会弹出「安装助手脚本」要求输入系统密码，属正常流程。Windows 版直接写入任务计划程序，无需额外授权。

移动端能不能设？

比特浏览器目前仅提供「环境同步」App，用于查看状态与接收告警，无法直接创建定时重启计划。若需外出修改，可远程连回桌面端，或使用官方开放的 127.0.0.1:xxxx/bitbrowser REST API 调用 /schedule/restart 接口，同样需要桌面端保持在线。

会话保持的技术边界

「恢复登录状态」≠「100% 不踢号」。下列场景仍可能触发二次验证：

• 重启前后 IP 归属国发生变动（住宅 IP 轮换导致）。
• 浏览器指纹字段被意外改写，如屏幕分辨率从 1920×1080 变成 1366×768。
• 网站自身策略：Amazon 每 96 h 强制校验一次，无论设备是否已知。

缓解办法：在「IP 轮换」里锁定「会话保持 IP」选项，或在指纹模板里把「随机变更」改为「固定实例」。

与 RPA 脚本协同

若你已用图形化 RPA 录制「自动发帖」流程，可在脚本末尾加一步「写入下次重启时间」到本地 SQLite，再通过 /schedule/restart API 动态调整。这样能把重启点精确放到任务低峰期，减少中断。

常见失败分支与回退

现象	最可能原因	快速验证	处置
计划任务显示「未执行」	客户端被手动退出	查看系统日志中是否无 bitbrowser 进程	把客户端设为「开机自启」并勾选「后台驻留」
重启后 Cookie 丢失	未勾选 IndexedDB	在环境目录下查看 /Default/IndexedDB 是否为空	编辑计划→保留字段→手动追加 IndexedDB
重启后 IP 改变	代理设为「按流量轮换」	对比重启前后 /ip 接口返回	把代理策略改为「会话保持」或「定时轮换」并延长周期

验证与观测方法

1. 在「系统监控」页打开「内存折线」面板，设定采样间隔 5 min。
2. 记录重启前的内存峰值与重启后的基线，计算差值。
3. 连续观察 3 个周期，若平均回收率＜30%，说明重启间隔仍可拉长；若回收率＞60%，可尝试把间隔缩短 1 h，进一步降低卡顿。

不适用场景清单

• 需要 7×24 h 不间断在线的 WebSocket 交易环境，重启会导致行情断链。
• 使用硬件 UKey 登录的网银，重启后需重新插拔验证，无法自动化。
• 团队 Viewer 角色账号：无「批量维护」权限，入口不可见。

最佳实践 6 条

1. 首次配置先选 2 个环境做 A/B：一个重启，一个不重启，对比 24 h 内存与登录状态。
2. 对「高价值店铺」单独分组，重启间隔≥12 h，并绑定住宅固定 IP。
3. 重启前 10 min 通过 RPA 自动保存未提交订单，防止数据丢失。
4. 把重启计划写进团队共享日历，方便值班人员知晓维护窗口。
5. 每月检查一次「计划任务」是否被系统清理（尤其 macOS 升级后）。
6. 若平台强制双重验证，提前在密码管理器更新验证码密钥，减少人工干预。

FAQ

收尾：下一步行动

先选 2 个环境跑 24 h 对比，确认内存回收与登录状态无异常后，再推广到全组；同时把重启窗口对齐业务低峰，并每月复查计划任务是否被系统清理。这样既能享受定时重启带来的内存红利，又能最大限度保留平台信任，减少二次验证带来的运营中断。