在"纯 UI 登录"这个架构里,已经把频次压到理论下限了，方案如下：
✅ 登录频次:已经是这套架构的下限
场景 改造前和现在对比
一轮套件(56 条) 每条独立登录的风险 + 手工调试 1 次(session 级共享)
180 秒内重复跑 每次都登录 0 次(缓存命中,直接跳过)
套件中途会话过期 后面全挂 +1 次(自愈重登,罕见)
调试期实测 ~10 次/1.5 小时 稳态 ≈ 每轮 1 次
再往下压就没有物理空间了------token 寿命只有 5 分钟(expires_in: 300),缓存不可能比会话本身活得久。
⚠️ 但"不触发风控"取决于两件事,频次只是其一自动化指纹:Playwright 驱动的浏览器有 navigator.webdriver 等特征,微软登录页对此极敏感。即使低频,长期同一账号+同一指纹+同一 IP 做自动化登录,风险分也会慢慢积累。
改造前拦截就是"上午高频 × 自动化特征"叠加引爆的,而且拦截冷却期可能还没过(建议 13:35 之后再试)。
调试期行为:风控不是被"正常回归"打爆的,是被"调试期连续 10 次跑"打爆的。新机制下同样的习惯还是会产生 10 次登录。
实操建议(把风险再降一档)
调试合并跑:改几条用例后,一次 pytest -k "A or B or C" 跑完,不要一条条触发(每次触发 = 至少 1 次登录);
失败就停手:如果重登又见白屏,立刻停止所有自动化(包括我的探测脚本),说明还在拦截期,继续硬试只会延长冷却、甚至锁账号;
治本只有一条路:找用户中心管理员给账号xxxxx(或申请专用测试账号)做条件访问/自动化登录白名单。
拿到白名单后,频次和指纹都不是问题了------这是企业内 UI 自动化的标准姿势,建议这周就提工单;
验证方法:冷却后手动登录一次确认账号正常 → 跑一轮套件(登录 1 次)→ 3 分钟内再跑一轮,看到 login ✓ 命中登录会话缓存 即证明缓存链路工作正常。
一句话总结:代码侧能做的已经做满了,剩下的风险在账号策略层面,白名单才是根治方案。