merge: 合并 dev 并解决 PR 冲突

README.md

@@ -53,6 +53,7 @@
 - 自动显示当前使用中的密码，便于后续保存
 - 自动获取注册验证码与登录验证码
 - 支持 `Hotmail`：继续使用 `邮箱 + 客户端 ID + 刷新令牌（refresh token）`，并可在远程服务与本地助手两种模式间切换
+- 支持 `2925`：新增多账号池、自动登录登出、Step 4 / Step 8 命中“子邮箱已达上限邮箱”后的 24 小时禁用与自动切号
 - 支持 `QQ Mail`、`163 Mail`、`163 VIP Mail`、`126 Mail`、`Inbucket mailbox`
 - 支持从 DuckDuckGo Email Protection 自动生成新的 `@duck.com` 地址
 - 支持基于 Cloudflare 自定义域名自动生成随机邮箱前缀
@@ -80,33 +81,34 @@
 ## 安装
 
 1. 打开 `chrome://extensions/`
+2. 开启“开发者模式”
+3. 点击“加载已解压的扩展程序”
+4. 选择本项目目录
+5. 打开扩展侧边栏
 
 ## 2026-04-17 更新补充：Gmail / 2925 别名邮箱
 
-本次版本对 `Gmail` 与 `2925` 的注册邮箱逻辑做了统一整理：
+本次版本对 `Gmail` 与 `2925 provide` 的注册邮箱逻辑做了统一整理：
 
-- `Gmail` 与 `2925` 现在都走同一套“别名邮箱”逻辑。
+- `Gmail` 与 `2925 provide` 现在都走同一套“别名邮箱”逻辑。
 - 两者都不再使用“只填前缀再特殊拼接”的界面交互。
 - 两者都要求先填写“基邮箱”：
   - `Gmail`：例如 `name@gmail.com`
-  - `2925`：例如 `name@2925.com`
+  - `2925`（仅 provide 模式）：例如 `name@2925.com`
 - 侧边栏里的“注册邮箱”输入框对这两种模式都已开放，可直接手动填写完整邮箱。
 - 侧边栏里的 `获取 / 生成` 按钮对这两种模式也可用，行为与 Duck / Cloudflare 一样，都是“可自动生成，也可手动覆盖”。
+- 当 `Mail = 2925` 且模式切到 `接收邮箱` 时，不再走别名基邮箱链路，而是回退到普通“邮箱生成 / 手动填写注册邮箱”路线，2925 只负责后续收信。
 
 具体行为：
 
 - `Gmail` 会基于完整基邮箱生成 `name+tag@gmail.com`
-- `2925` 会基于完整基邮箱生成 `name123456@2925.com`
+- `2925` 仅在 provide 模式下会基于完整基邮箱生成 `name123456@2925.com`
 - 如果当前“注册邮箱”里已经是与当前基邮箱兼容的完整邮箱，流程会优先复用，不会强行重新生成
 
 注意：
 
 - `2925` 旧的“只填前缀”使用方式已经不再推荐，应该改为填写完整基邮箱
-- 如果你手动填写了与当前 `Gmail / 2925` 基邮箱不匹配的完整邮箱，侧边栏会在保存或执行 Step 3 时拦截
-2. 开启“开发者模式”
-3. 点击“加载已解压的扩展程序”
-4. 选择本项目目录
-5. 打开扩展侧边栏
+- 如果你手动填写了与当前 `Gmail / 2925 provide` 基邮箱不匹配的完整邮箱，侧边栏会在保存或执行 Step 3 时拦截
 
 ## 快速开始
 
@@ -130,7 +132,15 @@
 4. Step 1 会直接在 SUB2API 后台生成 OAuth 链接
 5. Step 10 会把 localhost 回调提交回 SUB2API，并直接创建 OpenAI 账号
 
-### 方案 C：`Hotmail 账号池`
+### 方案 C：`Codex2API + QQ / 163 / 163 VIP / 126`
+
+1. `来源` 选择 `Codex2API`
+2. 填好 `Codex2API` 后台地址、管理密钥
+3. `Mail` 与 `邮箱生成` 的配置方式同方案 A
+4. Step 7 会直接通过 Codex2API 协议 `/api/admin/oauth/generate-auth-url` 生成 OAuth 链接
+5. Step 10 会把 localhost 回调中的 `code / state` 通过 `/api/admin/oauth/exchange-code` 直接提交给 Codex2API
+
+### 方案 D：`Hotmail 账号池`
 
 1. `Mail` 选择 `Hotmail`
 2. 在 `Hotmail 账号池` 中添加 `邮箱 / Client ID / Refresh Token`
@@ -138,6 +148,20 @@
 4. 通过后再执行步骤或 `Auto`
 5. 当前项目中，`Mail = Hotmail` 时会直接使用账号池里的邮箱作为注册邮箱，不再走 `Duck / Cloudflare` 自动生成
 
+### 方案 E：`2925 账号池`
+
+1. `Mail` 选择 `2925`
+2. 在 `2925 账号池` 中添加 `邮箱 / 密码`
+3. 先根据你的用途选择 `2925 模式`
+   - `提供邮箱`：注册邮箱本身就是 2925 别名，会显示“别名基邮箱”输入
+   - `接收邮箱`：注册邮箱回退到普通“邮箱生成 / 手动填写”路线，2925 只负责收信
+4. `2925 号池` 现在是独立配置行；开启 `号池` 后可从下拉框中选择当前 2925 账号。若当前处于 `提供邮箱` 模式，这个账号也会同步作为别名基邮箱
+5. 可先点 `使用此账号` 让当前 2925 账号切到这条记录，再点 `登录` 手动验证网页邮箱登录态
+6. 只有在 `号池` 开关开启时，自动流程执行到 Step 4 / Step 8 前才会自动检查 2925 登录态；如果未登录，会先清理登录 cookie、等待 `3 秒`，再打开登录页，并在页面打开后再等待 `3 秒`，然后使用当前账号自动登录；填写完账号密码后会额外等待 `1 秒` 再点击登录，点击后若 `40 秒`内仍未进入收件箱，则会判定当前登录失败
+7. 当 Step 4 / Step 8 轮询邮箱时遇到“子邮箱已达上限邮箱”，扩展会记录当前时间；如果还有下一个可用账号，就禁用当前账号 24 小时并自动切换登录；如果没有下一个可用账号，或当前未启用号池模式，则会直接复用现有“手动暂停 / 停止”逻辑终止自动流程
+8. 如果你同时开启了 `Auto` 的自动重试，当前尝试结束后会按现有逻辑自动进入下一次尝试，不需要再手动介入
+9. 只有 `Mail = 2925` 且模式为 `提供邮箱` 时，才会继续走 Gmail / 2925 共用的别名邮箱链路；例如 `name@2925.com -> name123456@2925.com`
+
 ## 侧边栏配置说明
 
 ### `CPA`
@@ -161,11 +185,26 @@ Step 1 和 Step 10 都依赖这个地址。
 
 插件会在 Step 1 和 Step 10 自动从 `/api/v1/admin/proxies/all` 解析这个代理，并在 OAuth 链接生成、授权码交换和账号创建请求中附带 `proxy_id`。如果名称匹配到多个代理，请改填代理 ID；留空则不会发送 `proxy_id`。
 
+### `Codex2API`
+
+当 `来源 = Codex2API` 时，需要配置：
+
+- `Codex2API`：后台账号管理页地址，默认 `http://localhost:8080/admin/accounts`
+- `管理密钥`：Codex2API 的 `Admin Secret`
+
+插件会在：
+
+- Step 7 调用 `POST /api/admin/oauth/generate-auth-url` 生成授权链接
+- Step 10 调用 `POST /api/admin/oauth/exchange-code` 完成 localhost callback 的授权码交换并创建账号
+
+这条来源是协议直连，不依赖 Codex2API 后台页面的“添加账号 / OAuth 授权 / 生成授权链接”按钮 DOM。
+
 ### `Mail`
 
-支持五种验证码来源：
+支持七种验证码来源：
 
 - `Hotmail`
+- `2925`
 - `163 Mail`
 - `163 VIP Mail`
 - `126 Mail`
@@ -175,6 +214,7 @@ Step 1 和 Step 10 都依赖这个地址。
 说明：
 
 - `Hotmail` 通过侧边栏里的 Hotmail 账号池选择账号，可切换为远程服务模式或本地助手模式
+- `2925` 通过侧边栏里的 2925 账号池选择账号，并在 Step 4 / Step 8 前自动校验网页邮箱登录态
 - `QQ`、`163`、`163 VIP`、`126` 用于直接轮询网页邮箱
 - `Inbucket` 通过你在侧边栏里配置的 host 访问 `mailbox` 页面：`https://<your-inbucket-host>/m/<mailbox>/`
 
@@ -208,6 +248,24 @@ Step 1 和 Step 10 都依赖这个地址。
 - 校验通过后，可点击 `测试收信`
 - Auto 模式每轮会自动选用一个可用账号
 
+### `2925 账号池`
+
+仅当 `Mail = 2925` 时使用。
+
+每条账号支持保存：
+
+- `email`
+- `password`
+
+使用方式：
+
+- 添加一个或多个 `2925.com` 账号
+- 点击 `使用此账号` 可以切换当前别名基邮箱来源
+- 点击 `登录` 可以让扩展直接打开 / 复用 2925 邮箱标签页，并使用当前账号自动登录
+- 如果账号因为“子邮箱已达上限邮箱”被临时禁用，列表里会展示上限记录时间和恢复时间
+- 命中冷却的账号可手动 `清冷却`，也可以等待 24 小时后自动恢复可用
+- Auto 模式在生成 2925 别名邮箱前，会自动分配当前可用账号；若 Step 4 / Step 8 命中上限，会自动切到下一个账号
+
 #### 本地 helper 启动命令
 
 Windows：
@@ -493,7 +551,7 @@ Cloudflare 模式下，插件不会再调用 Cloudflare API 创建路由。
 - 使用第 2 步已经确定好的邮箱
 - 使用自定义密码或自动生成密码
 - 在密码页填写密码并提交注册表单
-- 后台会在真正把 Step 3 记为完成前，再确认页面是否已经推进；如果此时出现认证页 `重试` 页面，会先通过共享恢复逻辑最多自动点击 5 次 `重试` 尝试恢复，再继续后续链路
+- 后台会在真正把 Step 3 记为完成前，再确认页面是否已经推进；如果此时出现认证页 `重试` 页面，或 `/email-verification` 上的 `405 / Route Error` 重试页，会先通过共享恢复逻辑最多自动点击 5 次 `重试` 尝试恢复，再继续后续链路
 
 实际使用的密码会写入会话状态，并同步到侧边栏显示。
 
@@ -501,9 +559,10 @@ Cloudflare 模式下，插件不会再调用 Cloudflare API 创建路由。
 
 根据 `Mail` 配置，轮询邮箱并提取 6 位验证码。
 
-进入邮箱轮询前，脚本会先确认认证页是否已经进入验证码页面；如果密码页出现 `糟糕，出错了 / 操作超时（Operation timed out）` 并带有 `重试` 按钮，会先通过共享恢复逻辑最多自动点击 5 次 `重试`，回到密码页重新提交，再继续等待验证码页面。
+进入邮箱轮询前，脚本会先确认认证页是否已经进入验证码页面；如果注册认证流程出现 `糟糕，出错了 / 操作超时（Operation timed out）`，或 `/email-verification` 上的 `405 / Route Error` 且带有 `重试` 按钮，会先通过共享恢复逻辑最多自动点击 5 次 `重试`，必要时回到密码页重新提交，再继续等待验证码页面。
 
 在 `Auto` 模式下，如果 Step 4 当前轮失败，后台不会立刻丢弃这轮邮箱；而是沿用当前邮箱回到 Step 1 重新开始当前轮，避免刚拿到的邮箱被直接换掉。
+但如果 Step 4 的认证重试页正文里出现 `user_already_exists`，则会直接判定“当前用户已存在”，不会点击 `重试`，而是立即结束当前轮；开启自动重试时会直接继续下一轮。
 
 支持：
 
@@ -548,9 +607,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 确认稳定进入”的登录验证码页，只在后台入口做防御性状态兜底
 
 支持：
 
@@ -567,7 +628,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 类似，但会使用稍微不同的关键词组合去找登录验证码邮件。
@@ -586,7 +647,7 @@ Step 8 默认要求当前认证页已经处于登录验证码页。
 - 等待按钮可点击
 - 获取按钮坐标
 - 通过 Chrome `debugger` 的输入事件点击该按钮
-- 点击后会持续检查页面是否真正离开当前状态；如果出现认证页 `重试` 页面，会先通过共享恢复逻辑最多自动点击 5 次 `重试` 尝试恢复，再重新执行当前轮的“继续”点击
+- 点击后会持续检查页面是否真正离开当前状态；如果点击后出现认证页 `重试` 页面，则直接报错，不会在 Step 9 内部点击 `重试`
 - 同时监听 `chrome.webNavigation.onBeforeNavigate`
 - 一旦捕获本地回调地址，就把结果保存到 `Callback`
 
@@ -602,9 +663,9 @@ Step 8 默认要求当前认证页已经处于登录验证码页。
 
 - 步骤 10 会拒绝任何不是真实 `/auth/callback`，或缺少 `code` / `state` 的本地回调地址
 - 成功后的清理只会针对 `/auth` 这一类真实回调标签页，不会再泛化清理任意 localhost 路径
-- 侧边栏可切换“本地 CPA”策略，默认是 `全部回调`
-- 选择 `全部回调` 时，即使 CPA 部署在本地，也会执行步骤 10
-- 选择 `跳过第10步` 时，仅当本地 CPA 且步骤 9 已拿到回调地址时，才会直接跳过步骤 10
+- 侧边栏可切换“回调方式”，默认是 `服务器部署`
+- 选择 `服务器部署` 时，即使 CPA 部署在本地，也会执行步骤 10
+- 选择 `本地部署` 时，仅当本地 CPA 且步骤 9 已拿到回调地址时，才会直接跳过步骤 10
 
 回到 CPA 面板：