会话只活两小时：无人值守脚本要按 Cookie 成本来设计

先放今天的实测时间线（同一个账号、同一套 hw_profile）：

07:03  定时任务发现登录态失效 -> 帐密自动重登 -> 收割三份 Cookie，任务正常跑完
14:12  python hw_login_tool.py --check
       成长中心 Cookie: 失效 | not login
       码道 Cookie:    失效
       云实验 Cookie:  失效 | HD.32110001 auth error
14:20  --auto 重登成功（成长中心√ 码道√ 云实验√），立刻用：接口全通
14:40  期间起过一个复用 hw_profile 的浏览器，再查：又是 not login
18:55  重登 -> 从已登录浏览器 --refresh 收割 -> 接口恢复

也就是说这套会话的可用窗口是按小时算的，不是按天算。而且不是「过期」这么简单：同一 profile 里每多一次登录，前一份收割到磁盘的 Cookie 就被顶掉。

三条由此改掉的设计原则

一、把要外发的动作挤进同一个进程。之前我喜欢分步跑：先跑脚本 A 查状态，再想想要不要跑 B，中间顺手开个浏览器看看页面。在按小时掉线的会话上，这就是自己制造 403。现在的做法是一个进程里「收割 → 读 → 写 → 回查」一次做完，读结果用轮询而不是重跑。

二、能 --refresh 就别 --auto。浏览器已经是登录态时，收割只要几秒；重登要走帐密提交、等待跳转、可能撞滑块，而且会把别的会话打死。我现在的顺序是：先看 --check，只有浏览器侧也死了才 --auto。

三、判据必须用最小的真实写接口。半死的会话会让 GET growth/bonus-beans 照常返回数字

{"beans": 770}

r = s.post(MISSION_URL, json={"page_no": 1, "page_size": 5}, headers={"csrf": tok})
ok = r.status_code == 200 and "QueryMissionDtoList" in (r.text or "")

两个容易忽略的细节

UA 也要一致。华为云把会话绑在 User-Agent 上：无头默认 UA 登录出来的 Cookie，拿脚本里的正常 UA 去重放就是 403 not login，反过来也一样。所以启动浏览器时用 --user-agent= 把 UA 钉成和 requests 同一个。

设备信任记在 profile 里。换全新 profile 用同一份帐密登录，立刻被要求「验证您的身份」（短信或邮箱二选一），无人值守就死在那儿。所以只能固定复用同一个 profile，代价是同一时刻只允许一个浏览器实例占着它——登录前得先把占着的实例关掉，这一点要和「9333 是人机共用的观察窗口」分开设计，登录用独立端口。

结论：会话寿命是个要量出来的数，不是「大概几天」的感觉。量出来是按小时，脚本的批处理边界、收割顺序、判据强度就都得跟着重写一遍。