507 lines
17 KiB
Markdown
507 lines
17 KiB
Markdown
# 项目完整链路说明
|
||
|
||
本文档面向 AI 与开发者,目标是让阅读者在最短时间内理解“项目做什么、怎么跑、数据怎么流、功能链路怎么串”,从而在新增功能时不漏逻辑、不误改边界。
|
||
|
||
使用建议:
|
||
|
||
1. 先阅读 [项目文件结构说明.md](c:/Users/projectf/Downloads/codex注册扩展/项目文件结构说明.md)
|
||
2. 再阅读本文
|
||
3. 最后阅读 [项目开发规范(AI协作).md](c:/Users/projectf/Downloads/codex注册扩展/项目开发规范(AI协作).md)
|
||
|
||
## 1. 项目目标
|
||
|
||
这是一个 Chrome 扩展,用于自动执行一整套 OpenAI / ChatGPT OAuth 注册与登录流程。
|
||
|
||
它的核心价值不是“打开一个页面点几个按钮”,而是把下面这些环节串成一条完整可恢复的自动化链路:
|
||
|
||
- 生成或选取注册邮箱
|
||
- 打开 ChatGPT / OpenAI 注册入口
|
||
- 提交邮箱和密码
|
||
- 轮询注册验证码
|
||
- 填写姓名和生日
|
||
- 刷新 OAuth 链接并登录
|
||
- 轮询登录验证码
|
||
- 自动确认 OAuth 同意页
|
||
- 把 localhost 回调提交到 CPA 或 SUB2API
|
||
|
||
## 2. 核心运行参与者
|
||
|
||
### 2.1 Sidepanel
|
||
|
||
[sidepanel/sidepanel.html](c:/Users/projectf/Downloads/codex注册扩展/sidepanel/sidepanel.html) + [sidepanel/sidepanel.js](c:/Users/projectf/Downloads/codex注册扩展/sidepanel/sidepanel.js)
|
||
|
||
职责:
|
||
|
||
- 展示配置与步骤状态
|
||
- 接收用户输入
|
||
- 向后台发送命令
|
||
- 接收后台广播并更新 UI
|
||
- 动态渲染步骤列表
|
||
- 在日志区通过“记录”按钮打开独立的邮箱记录覆盖层,并展示成功/失败/重试统计与分页列表
|
||
|
||
### 2.2 Background Service Worker
|
||
|
||
[background.js](c:/Users/projectf/Downloads/codex注册扩展/background.js)
|
||
|
||
职责:
|
||
|
||
- 扩展后台入口
|
||
- 装配所有模块
|
||
- 统一承接 runtime message
|
||
- 协调步骤执行
|
||
- 管理状态、自动运行、标签页与内容脚本通信
|
||
|
||
### 2.3 Content Scripts
|
||
|
||
[content](c:/Users/projectf/Downloads/codex注册扩展/content)
|
||
|
||
职责:
|
||
|
||
- 在目标网页上执行 DOM 交互
|
||
- 读取邮件内容或页面状态
|
||
- 将步骤成功/失败状态上报给后台
|
||
|
||
### 2.4 Helper / Utils / Provider Logic
|
||
|
||
分布在根目录和 `background/` 下。
|
||
|
||
职责:
|
||
|
||
- 抽离第三方邮箱 provider 的纯逻辑
|
||
- 抽离邮件匹配与验证码提取
|
||
- 抽离共享验证码流程、自动运行流程和运行时基础设施
|
||
|
||
## 3. 入口与装配关系
|
||
|
||
### 3.1 扩展入口
|
||
|
||
[manifest.json](c:/Users/projectf/Downloads/codex注册扩展/manifest.json) 声明:
|
||
|
||
- `background.service_worker = background.js`
|
||
- `side_panel.default_path = sidepanel/sidepanel.html`
|
||
- 多组内容脚本自动注入规则
|
||
|
||
### 3.2 背景层装配
|
||
|
||
[background.js](c:/Users/projectf/Downloads/codex注册扩展/background.js) 通过 `importScripts(...)` 依次加载:
|
||
|
||
- 共享数据与纯工具
|
||
- provider 纯逻辑
|
||
- 后台桥接层
|
||
- 后台共享流程层
|
||
- 后台运行时与消息路由层
|
||
- 步骤执行模块
|
||
|
||
因此 `background.js` 现在更像:
|
||
|
||
- 常量定义中心
|
||
- 模块依赖装配器
|
||
- 极少量保留函数
|
||
- Chrome 事件挂接入口
|
||
|
||
### 3.3 步骤注册
|
||
|
||
[data/step-definitions.js](c:/Users/projectf/Downloads/codex注册扩展/data/step-definitions.js) 提供共享步骤元数据。
|
||
[background/steps/registry.js](c:/Users/projectf/Downloads/codex注册扩展/background/steps/registry.js) 负责把“步骤元数据”映射到“步骤执行器”。
|
||
|
||
这意味着:
|
||
|
||
- 步骤顺序靠 `order`
|
||
- 步骤文件名靠语义
|
||
- 新增步骤时不需要重命名后续文件
|
||
|
||
## 4. 状态与存储链路
|
||
|
||
### 4.1 `chrome.storage.session`
|
||
|
||
保存运行态:
|
||
|
||
- 当前步骤状态
|
||
- OAuth 链接
|
||
- 当前邮箱 / 密码
|
||
- localhost 回调地址
|
||
- 自动运行轮次信息
|
||
- 标签注册表
|
||
- 最近打开的来源地址
|
||
- LuckMail 当前运行时选择
|
||
|
||
### 4.2 `chrome.storage.local`
|
||
|
||
保存持久配置与账号运行历史:
|
||
|
||
- CPA / SUB2API 配置
|
||
- 邮箱 provider 配置
|
||
- Hotmail 账号池
|
||
- Cloudflare / Temp Email 设置
|
||
- iCloud 相关偏好
|
||
- LuckMail API 配置
|
||
- 自动运行默认配置
|
||
- 账号运行历史 `accountRunHistory`
|
||
- 账号运行历史本地同步开关与 helper 地址
|
||
|
||
当启用了独立的账号运行历史本地同步配置时,账号运行历史会通过 [scripts/hotmail_helper.py](c:/Users/projectf/Downloads/codex注册扩展/scripts/hotmail_helper.py) 整体同步写入 `data/account-run-history.json` 快照文件,便于开发者直接查看完整记录。
|
||
这条配置链路独立于 `mailProvider` 和 Hotmail 的接码模式。
|
||
|
||
### 4.3 状态广播
|
||
|
||
后台通过 runtime message 向 sidepanel 广播:
|
||
|
||
- `LOG_ENTRY`
|
||
- `STEP_STATUS_CHANGED`
|
||
- `DATA_UPDATED`
|
||
- `AUTO_RUN_STATUS`
|
||
- `ICLOUD_LOGIN_REQUIRED`
|
||
- `ICLOUD_ALIASES_CHANGED`
|
||
|
||
## 5. 内容脚本通信链路
|
||
|
||
### 5.1 READY 机制
|
||
|
||
[content/utils.js](c:/Users/projectf/Downloads/codex注册扩展/content/utils.js) 在脚本加载后会发送 `CONTENT_SCRIPT_READY`。
|
||
|
||
后台收到后会:
|
||
|
||
- 注册当前来源对应的 tab
|
||
- 标记 ready
|
||
- 冲刷排队命令
|
||
|
||
### 5.2 队列与重试
|
||
|
||
[background/tab-runtime.js](c:/Users/projectf/Downloads/codex注册扩展/background/tab-runtime.js) 负责:
|
||
|
||
- `queueCommand`
|
||
- `flushCommand`
|
||
- `sendTabMessageWithTimeout`
|
||
- `sendToContentScriptResilient`
|
||
- `sendToMailContentScriptResilient`
|
||
|
||
这保证了:
|
||
|
||
- 页面切换导致脚本暂时失联时,后台不会立刻误判彻底失败
|
||
- 邮箱页或注册页能在注入恢复后继续执行
|
||
|
||
## 6. 手动步骤完整链路
|
||
|
||
### Step 1
|
||
|
||
文件:
|
||
|
||
- [background/steps/open-chatgpt.js](c:/Users/projectf/Downloads/codex注册扩展/background/steps/open-chatgpt.js)
|
||
- [content/signup-page.js](c:/Users/projectf/Downloads/codex注册扩展/content/signup-page.js)
|
||
|
||
流程:
|
||
|
||
1. 后台打开 ChatGPT 官网
|
||
2. 等待注册入口页内容脚本就绪
|
||
3. 标记 Step 1 完成
|
||
|
||
补充:
|
||
|
||
- 手动点击“跳过步骤 1”时,会级联将步骤 2~5 标记为跳过;其中已完成或正在运行的步骤不会被改写。
|
||
|
||
### Step 2
|
||
|
||
文件:
|
||
|
||
- [background/steps/submit-signup-email.js](c:/Users/projectf/Downloads/codex注册扩展/background/steps/submit-signup-email.js)
|
||
|
||
流程:
|
||
|
||
1. 解析本轮应使用的邮箱
|
||
2. 打开或复用注册页
|
||
3. 点击注册入口并提交邮箱
|
||
4. 等待邮箱提交后的真实落地页
|
||
5. 如果进入密码页,则继续执行 Step 3
|
||
6. 如果直接进入邮箱验证码页,则自动跳过 Step 3 并进入 Step 4
|
||
|
||
### Step 3
|
||
|
||
文件:
|
||
|
||
- [background/steps/fill-password.js](c:/Users/projectf/Downloads/codex注册扩展/background/steps/fill-password.js)
|
||
|
||
流程:
|
||
|
||
1. 生成或读取密码
|
||
2. 更新运行态密码
|
||
3. 记录账号快照
|
||
4. 让内容脚本填写密码
|
||
5. 内容脚本先上报 Step 3 完成信号
|
||
6. 上报完成后再异步点击提交,避免页面跳转打断响应通道
|
||
7. 后台在真正确认 Step 3 完成前,会额外检查提交后是否切换页面;如果出现认证页 `Try again / 重试` 页面,会先自动点击 `重试` 恢复,再继续后续链路
|
||
|
||
### Step 4 / Step 7
|
||
|
||
文件:
|
||
|
||
- [background/steps/fetch-signup-code.js](c:/Users/projectf/Downloads/codex注册扩展/background/steps/fetch-signup-code.js)
|
||
- [background/steps/fetch-login-code.js](c:/Users/projectf/Downloads/codex注册扩展/background/steps/fetch-login-code.js)
|
||
- [background/verification-flow.js](c:/Users/projectf/Downloads/codex注册扩展/background/verification-flow.js)
|
||
|
||
这两步共享验证码主流程:
|
||
|
||
1. 确定 provider
|
||
2. 必要时重发验证码
|
||
3. 轮询邮箱或 API
|
||
4. 提取验证码
|
||
5. 回填页面
|
||
6. 若页面拒绝,则重试或回退
|
||
|
||
补充行为:
|
||
|
||
- `2925` provider 会拉长单轮轮询窗口,并关闭 Step 4 / 8 的自动重发间隔,减少因邮件延迟过早判负。
|
||
- Step 4 / 8 会在当前验证码步骤启动时固定一次邮件筛选时间窗;本步后续即使触发重新发送验证码,也继续沿用这一次启动时间作为筛选基准,不再随着重发时间前移。
|
||
- 自动重新发送验证码次数现在使用 sidepanel 里的单一“验证码重发”配置;普通邮箱仍按 25 秒间隔节流,Hotmail / 2925 不走这个 25 秒间隔。Step 4 若启用先请求新验证码,会先消耗一次当前步骤的自动重发次数。
|
||
|
||
- Auto 模式下,如果 Step 4 当前轮失败,后台会沿用当前邮箱回到 Step 1 重新开始当前轮,而不是立刻换邮箱开新尝试。
|
||
|
||
### Step 5
|
||
|
||
文件:
|
||
|
||
- [background/steps/fill-profile.js](c:/Users/projectf/Downloads/codex注册扩展/background/steps/fill-profile.js)
|
||
|
||
流程:
|
||
|
||
1. 生成随机姓名和生日
|
||
2. 内容脚本填写资料并点击“完成帐户创建”
|
||
3. 点击后立即上报 Step 5 完成,不再等待页面结果
|
||
4. 自动运行在进入 Step 6 前仅额外等待当前页面加载完成,不再在 Step 5 阶段接管 ChatGPT 跳转或 onboarding 跳过
|
||
|
||
### Step 6
|
||
|
||
文件:
|
||
|
||
- [background/steps/clear-login-cookies.js](c:/Users/projectf/Downloads/codex注册扩展/background/steps/clear-login-cookies.js)
|
||
|
||
流程:
|
||
|
||
1. 等待登录前清理延迟
|
||
2. 直接删除 ChatGPT / OpenAI cookies
|
||
3. 必要时用 `browsingData` 补扫 cookies
|
||
4. 完成后进入后续登录链路
|
||
|
||
### Step 7
|
||
|
||
文件:
|
||
|
||
- [background/steps/oauth-login.js](c:/Users/projectf/Downloads/codex注册扩展/background/steps/oauth-login.js)
|
||
|
||
流程:
|
||
|
||
1. 通过 CPA / SUB2API 刷新 OAuth 地址
|
||
2. 打开最新 OAuth 链接
|
||
3. 登录
|
||
4. 确保真正进入验证码页
|
||
5. 如果未进入验证码页,则按可恢复逻辑最多重试 3 次
|
||
6. 自动运行一旦进入步骤 7 之后的链路,若后续步骤报错且认证页未进入 `https://auth.openai.com/add-phone`,则统一回到步骤 7 重新开始授权流程
|
||
|
||
### Step 8
|
||
|
||
文件:
|
||
|
||
- [background/steps/fetch-login-code.js](c:/Users/projectf/Downloads/codex注册扩展/background/steps/fetch-login-code.js)
|
||
|
||
流程:
|
||
|
||
1. 确认当前认证页已经进入登录验证码页
|
||
2. 打开邮箱页或 API 轮询入口
|
||
3. 轮询登录验证码
|
||
4. 回填登录验证码
|
||
5. 如遇邮箱轮询类失败,则按有限次数回到 Step 7 重试
|
||
6. 获取到登录验证码后不再触发“刷新 OAuth 并重走 Step 7”的前置回放,直接在当前验证码页提交并继续进入 Step 9
|
||
|
||
### Step 9
|
||
|
||
文件:
|
||
|
||
- [background/steps/confirm-oauth.js](c:/Users/projectf/Downloads/codex注册扩展/background/steps/confirm-oauth.js)
|
||
|
||
流程:
|
||
|
||
1. 监听 localhost callback
|
||
2. 准备 OAuth 同意页
|
||
3. 尝试多轮点击“继续”
|
||
4. 一旦捕获 localhost callback,写入状态并完成步骤
|
||
|
||
### Step 10
|
||
|
||
文件:
|
||
|
||
- [background/steps/platform-verify.js](c:/Users/projectf/Downloads/codex注册扩展/background/steps/platform-verify.js)
|
||
|
||
流程:
|
||
|
||
1. 校验 localhost callback 是否有效
|
||
2. 判断是 CPA 还是 SUB2API
|
||
3. 打开相应后台
|
||
4. 提交回调地址
|
||
5. 仅当出现精确成功徽标,且该徽标不是红色/错误态、页面上也没有同时可见的失败提示时,才判定成功
|
||
6. 识别 `认证失败:*`、`认证失败: timeout of 30000ms exceeded`、`回调 URL 提交失败: oauth flow is not pending` 等失败提示并立即报错
|
||
7. 完成平台侧验证
|
||
8. 追加账号运行历史成功记录
|
||
9. 做成功后的清理与标记
|
||
|
||
## 7. 邮箱与 provider 链路
|
||
|
||
### 7.1 2026-04-17 补充:Gmail / 2925 统一别名邮箱链路
|
||
|
||
本轮将 Gmail 与 2925 的注册邮箱逻辑统一收敛为“共享别名邮箱链路”:
|
||
|
||
- 两者都先填写“基邮箱”
|
||
- Gmail:`name@gmail.com`
|
||
- 2925:`name@2925.com`
|
||
- 两者都允许两种入口:
|
||
- 点击侧边栏按钮自动生成完整注册邮箱
|
||
- 直接在“注册邮箱”输入框中手动填写完整邮箱
|
||
|
||
当前行为约定:
|
||
|
||
1. sidepanel 展示“别名基邮箱”输入框,并根据当前 provider 显示对应文案
|
||
2. 点击 `获取 / 生成` 时:
|
||
- Gmail 生成 `name+tag@gmail.com`
|
||
- 2925 生成 `name123456@2925.com`
|
||
3. Step 2 / Step 3 进入注册流程前,会先判断当前 `state.email`
|
||
- 如果已经是与当前基邮箱兼容的完整邮箱,则直接复用
|
||
- 如果为空或不兼容,则按当前 provider 重新生成
|
||
4. 保存或执行 Step 3 时,如果手动填写的完整邮箱与当前 Gmail / 2925 基邮箱不兼容,sidepanel 会直接拦截
|
||
5. auto-run fresh attempt reset 时,会保留:
|
||
- `gmailBaseEmail`
|
||
- `mail2925BaseEmail`
|
||
|
||
### 7.2 共享模块分工
|
||
|
||
- `managed-alias-utils.js`
|
||
统一承接 Gmail / 2925 的:
|
||
- 基邮箱解析
|
||
- 完整邮箱兼容性判断
|
||
- 别名邮箱生成
|
||
- UI 文案输出
|
||
|
||
- `background/generated-email-helpers.js`
|
||
在原有 Duck / Cloudflare / iCloud / Cloudflare Temp Email 生成链路之外,新增 Gmail / 2925 的共享生成接入。
|
||
|
||
- `background/signup-flow-helpers.js`
|
||
负责在真正提交注册邮箱前做“复用已有完整邮箱 / 重新生成”的最终决策。
|
||
|
||
### 7.1 生成邮箱
|
||
|
||
文件:
|
||
|
||
- [background/generated-email-helpers.js](c:/Users/projectf/Downloads/codex注册扩展/background/generated-email-helpers.js)
|
||
|
||
支持:
|
||
|
||
- Duck
|
||
- Cloudflare
|
||
- Cloudflare Temp Email
|
||
- iCloud 隐私邮箱
|
||
|
||
### 7.2 Hotmail
|
||
|
||
组成:
|
||
|
||
- [hotmail-utils.js](c:/Users/projectf/Downloads/codex注册扩展/hotmail-utils.js)
|
||
- [microsoft-email.js](c:/Users/projectf/Downloads/codex注册扩展/microsoft-email.js)
|
||
- [scripts/hotmail_helper.py](c:/Users/projectf/Downloads/codex注册扩展/scripts/hotmail_helper.py)
|
||
|
||
模式:
|
||
|
||
- API 对接
|
||
- 本地 helper
|
||
|
||
补充:
|
||
|
||
- 本地 helper 除了收信与验证码读取,还提供邮箱记录 JSON 快照同步接口。
|
||
- 账号运行历史本地同步由独立配置控制,不再绑定 Hotmail 的本地助手模式。
|
||
|
||
### 7.3 LuckMail
|
||
|
||
组成:
|
||
|
||
- [luckmail-utils.js](c:/Users/projectf/Downloads/codex注册扩展/luckmail-utils.js)
|
||
- LuckMail 相关后台领域逻辑仍在 [background.js](c:/Users/projectf/Downloads/codex注册扩展/background.js)
|
||
|
||
### 7.4 iCloud
|
||
|
||
组成:
|
||
|
||
- [icloud-utils.js](c:/Users/projectf/Downloads/codex注册扩展/icloud-utils.js)
|
||
- [content/icloud-mail.js](c:/Users/projectf/Downloads/codex注册扩展/content/icloud-mail.js)
|
||
|
||
## 8. 自动运行完整链路
|
||
|
||
文件:
|
||
|
||
- [background/auto-run-controller.js](c:/Users/projectf/Downloads/codex注册扩展/background/auto-run-controller.js)
|
||
|
||
流程:
|
||
|
||
1. 读取总轮数与模式
|
||
2. 计算是否从中断点继续
|
||
3. 每轮执行前重置必要运行态
|
||
4. 执行 `runAutoSequenceFromStep`
|
||
- 步骤 7 内部仍保留登录态恢复的有限重试
|
||
- 一旦进入步骤 7~10,遇到普通报错且认证流程未进入 `add-phone`,则自动回到步骤 7 无限重开
|
||
- 如果是手动停止,则立即退出自动流程,不会再触发“回到步骤 7 重开”
|
||
5. 如果失败,根据设置决定:
|
||
- 立即停止
|
||
- 当前轮重试
|
||
- 下一轮继续
|
||
6. 当前轮最终失败时,写入邮箱记录,并在自动重试链路中累计重试次数
|
||
- 手动停止与自动停止不再进入新邮箱记录体系
|
||
7. 如果配置了线程间隔,则挂计时计划
|
||
8. 所有轮次结束后输出汇总
|
||
|
||
## 9. 新增功能时最容易漏掉的地方
|
||
|
||
### 新增步骤
|
||
|
||
必须同时检查:
|
||
|
||
1. [data/step-definitions.js](c:/Users/projectf/Downloads/codex注册扩展/data/step-definitions.js)
|
||
2. [background/steps](c:/Users/projectf/Downloads/codex注册扩展/background/steps)
|
||
3. [background/steps/registry.js](c:/Users/projectf/Downloads/codex注册扩展/background/steps/registry.js)
|
||
4. 自动运行链路是否需要纳入
|
||
5. Step 状态传播和侧边栏展示是否需要适配
|
||
6. 测试是否要补
|
||
|
||
### 新增 provider
|
||
|
||
必须同时检查:
|
||
|
||
1. provider 纯工具
|
||
2. 后台 provider 调度分支
|
||
3. 侧边栏配置项
|
||
4. 动态邮箱生成逻辑
|
||
5. Step 4 / 7 的验证码流
|
||
6. 成功收尾逻辑
|
||
|
||
### 新增配置项
|
||
|
||
必须同时检查:
|
||
|
||
1. `PERSISTED_SETTING_DEFAULTS`
|
||
2. `normalizePersistentSettingValue`
|
||
3. 导入导出逻辑
|
||
4. sidepanel 表单与状态恢复
|
||
5. 是否错误挂靠到无关 provider / manager 配置下
|
||
6. 结构文档 / 开发规范是否需要更新
|
||
|
||
## 10. 文档联动规则
|
||
|
||
修改下列内容时,必须同步更新文档:
|
||
|
||
- 文件结构变更
|
||
更新 [项目文件结构说明.md](c:/Users/projectf/Downloads/codex注册扩展/项目文件结构说明.md)
|
||
- 运行链路变更
|
||
更新 [项目完整链路说明.md](c:/Users/projectf/Downloads/codex注册扩展/项目完整链路说明.md)
|
||
- 规范、边界、步骤接入方式变更
|
||
更新 [项目开发规范(AI协作).md](c:/Users/projectf/Downloads/codex注册扩展/项目开发规范(AI协作).md)
|
||
## 2026-04 链路补充:认证页共享恢复
|
||
|
||
- 新增共享恢复层:`content/auth-page-recovery.js`。
|
||
- Step 4 在等待注册验证码页时,如果命中认证页 `Try again / 重试` 页,会先自动点击 `重试` 恢复,再继续回到密码页重提和验证码页确认流程。
|
||
- Step 7 在识别到登录超时报错页时,会先尝试自动点击 `重试` 恢复当前页面,再按原有有限重试逻辑重新执行整步。
|
||
- Step 9 在点击 OAuth 同意页 `继续` 后,会额外检查是否进入认证页重试页;若命中则先自动点击 `重试` 恢复,再重新执行当前轮的 `继续` 点击。
|