feat: 优化2925账号池表单，修复步骤7无法识别重试页面bug

2026-04-21 16:39:37 +08:00
parent 5c75d2e3aa
commit 9228c7080e
11 changed files with 532 additions and 51 deletions
@@ -579,9 +579,11 @@ Cloudflare 模式下，插件不会再调用 Cloudflare API 创建路由。

 - 已刷新到最新 OAuth 链接
 - 认证页已经真正进入登录验证码页面
+- 在真正把 Step 7 记为完成前，还会再做一轮收尾确认；如果页面只是短暂进入登录验证码页、随后又掉进登录重试页，则不会直接进入 Step 8，而是先按共享恢复逻辑处理并重跑 Step 7
 - 如遇登录超时报错，会先尝试通过共享恢复逻辑最多自动点击 5 次认证页上的 `重试` 恢复当前页面；若仍未恢复，再按既有逻辑重跑整个 Step 7
 - 如遇登录页长时间停滞，会由后台刷新 OAuth 后重跑整个 Step 7
 - 如果重试页内容中出现 `max_check_attempts`，会立刻完全停止流程，并在侧边栏复用现有确认弹窗提示这是 Cloudflare 风控拦截，确认按钮显示为“我知道了”
+- Step 8 不负责替代 Step 7 的收尾确认；它默认消费的是“已经由 Step 7 确认稳定进入”的登录验证码页，只在后台入口做防御性状态兜底

 支持：

@@ -598,7 +600,7 @@ Step 8 默认要求当前认证页已经处于登录验证码页。
 - 打开邮箱并轮询登录验证码
 - 填写并提交登录验证码
 - 验证码链路失败后按有限次数回退到 Step 7
- 如果进入登录超时报错/重试页，会直接报错并回到 Step 7，不会在 Step 8 内部点击 `重试`
+- 如果进入登录超时报错/重试页，包括 `/email-verification` 上的 `405 / Route Error` 登录重试页，会直接报错并回到 Step 7，不会在 Step 8 内部点击 `重试`
 - 如果重试页内容中出现 `max_check_attempts`，会直接完全停止整个流程，并复用现有确认弹窗提醒先等待 15 到 30 分钟或更换浏览器，确认按钮显示为“我知道了”

 与 Step 4 类似，但会使用稍微不同的关键词组合去找登录验证码邮件。