最近基于自己的实际需求，我做了一个 Chrome 扩展项目。这个项目的核心目标是让原本依赖人工操作、需要频繁切换页面和等待验证码的流程，变成一个可视化、可管理、可复用的自动化工具。

和只关注单次流程推进的方案不同，我更在意的是这几个问题：邮箱来源是否统一管理、验证码等待是否足够顺畅、流程跑完后状态是否可追踪、下一轮任务是否能自动避开已处理邮箱。

也正因为这样，这个项目最终落在了“可视化邮箱池管理、流程结果的标签闭环管理”上。

🔗项目地址：

这个项目发布后，GitHub 在 1 天内获得 260+ Stars。对我来说，这个结果很重要，因为它说明这个工具解决的是一个真实存在的问题，也说明这套思路得到了不少用户的验证和反馈。

为什么我会做这个项目

原贴： 自动化古法注册（4 月 14 号 13 点 v7.8.0 版本发布）【一键 CPA/SUB2api 认证 + gpt 注册 + 上传】Chrome 插件（四天不到 star 数已经破 1.2K 啦）

一开始我在使用现有方案时，遇到的主要问题有两个。

第一个问题是，邮箱接收体验不稳定。

有些邮箱（比如duck邮箱）来源收信速度慢，单次等待时间长，而且每日可用量有限，流程经常卡在验证码阶段。经验证hotmail等邮箱接收验证码会快很多，因此我修改了可接收验证码的邮箱。

第二个问题是，流程做完以后缺少状态管理。

当一个流程中途失败，或者跑了很多轮之后，很容易分不清哪些邮箱已经完成，哪些邮箱还没处理，哪些邮箱需要重试。这会直接带来重复消耗、人工回查和管理混乱。

所以我最后决定自己做一个版本，把重点放在“修改为支持多邮箱、可视化邮箱池管理、流程结果的标签闭环”上。

这个项目解决了什么问题

简单说，这个扩展做的事情就是：

1️⃣从邮箱池中拉取可用邮箱

2️⃣自动轮询验证码邮件并提取结果

3️⃣推进页面中的认证流程

4️⃣在流程完成后自动打标签，避免重复使用

为了实现这一点，我接入了成熟的多邮箱管理工具 Outlook Email，把原本分散的邮箱来源统一纳入一个可视化界面中。当前支持的邮箱来源包括：Outlook、Gmail、QQ、163、126、Yahoo、阿里邮箱、自定义IMAP，同时也兼容多种临时邮箱提供商能力，方便根据实际场景切换不同来源。

整个流程完成后，插件会自动给对应邮箱打上标签。下次运行时，优先从未打标签的邮箱中继续处理。

这样一方面，邮箱获取、验证码等待和账号切换被整合到了同一个界面里，使用过程更顺畅。另一方面，通过“已注册”这类标签管理，可以快速筛选未处理邮箱，实现状态闭环，减少遗漏和重复操作。

使用教程

1. 安装本扩展

   • 打开 github 仓库，clone 或下载 zip 到本地

   • 打开 chrome://extensions/

   • 开启 “开发者模式”

   • 点击 “加载已解压的扩展程序”

   • 选择当前目录 hotmail-register-extension

2. 部署并启动 Outlook Email 服务

   • 使用仓库：assast/outlookEmail，并按照 readme 指示成功部署

   • 确保你已经可以通过浏览器访问它的后台页面和 API（** 一定要先从浏览器打开一次前端！** 否则无法给邮箱打标签）

3. 获取 Outlook Email 的 API key 和 API URL

   • API URL 就是 Outlook Email 前端地址

   • API key 是打开 Outlook Email 前端，点击右上角设置，有一个 “对外 API”，点击生成即可

4. 配置插件

   • 在插件侧边栏填写 API URL、API key、CPA URL、管理密钥、默认登录密码

5. 开始运行

Q&A

1.hotmail 邮箱从哪里来？

• 可以直接购买，一般 2-6 分一个，买 100 个也不超过 10 元，对于个人使用已经足够了

• 如果有 hotmail 邮箱，可以参考佬友分享的方式： hotmail 插件注册机（90％成功率，两分钟一个） 点击这个项目里的 GitHub 仓库，仓库里有个 “别名邮箱生成”，可以一键生成别名邮箱。生成之后再导入 Outlook Email 里。

  

2. 第八步弹出 add-phone 进行不下去了？

这是 ip / 邮箱问题，hotmail 也小概率会出现。可以考虑放弃这个邮箱，标记为已注册，开始下一个

3. 卡在第二步，一直在 outh 页面，出不来注册页面，无法继续推进

这通常与节点环境有关，可以优先检查当前网络环境与页面状态。

4. 已经可以拉取邮箱，但标签没有正常同步 通常是因为邮箱管理端前端页面没有先在浏览器中打开，导致相关状态未建立。 按文档提示先访问一次前端页面即可。

测试结果：

开发中遇到的坑

很多人看到自动化扩展，第一反应会觉得无非是“自动点按钮”。但真正做下来之后，我发现最麻烦的部分其实在于流程稳定性。

这个项目涉及“CPA 面板、OAuth 页面、注册页、验证码获取、授权回调、标签同步”多个阶段。每个阶段都可能因为“页面语言、节点环境、邮箱类型、邮箱格式、页面结构变化、跳转时机差异、旧状态污染新一轮流程”这些因素导致失败。

所以这个项目真正的工作量，主要花在“流程状态识别、异常分支兼容、验证码轮询与提取策略、多轮任务重置与恢复、标签同步与日志可观测性”这些方面。

也正因为如此，我更愿意把它看成一个带状态推进和异常恢复能力的自动化系统，而不是一个一次性脚本。

在测试和维护过程中，我遇到过不少很真实的问题，这里也记录一下：

• 页面语言差异导致识别失败 最初很多识别逻辑是基于英文页面写的，但真实用户环境里存在中文页面，结果就是某些步骤会直接卡住。后面我补充了多语言兼容逻辑，降低了这类问题的出现概率。

• 多轮执行时页面状态没有正确重置 首轮成功后，下一轮流程可能仍然停留在旧页面状态，导致无法正常获取新的入口或继续推进。这个问题后来通过刷新与重置逻辑进行了修复。

• 验证码邮件格式并不统一 不同邮箱来源、不同阶段的邮件格式差异很大。有些验证码在标题里，有些在正文里，有些还会因为历史邮件干扰而误读。后续我调整了轮询与提取策略，并给是否读过邮件打了标签，减少了重复读取旧邮件的问题。

• 标签同步依赖前端访问状态 有一个非常容易忽略的细节是，如果邮箱管理端的前端页面从未在浏览器里打开过，就可能出现“能拉邮箱但不能打标签”的情况。这个问题后来也补充到了文档和提示信息里。

为什么我选择接入现成邮箱管理工具

一开始我也想过直接对接邮箱底层接口，但评估之后，我发现这样会把复杂度迅速拉高，主要考虑到、认证体系、Token 生命周期、后台管理、多邮箱来源统一抽象。这在开发中需要额外投入不少精力，相当于是重复造轮子。

所以我最后做了更现实的工程选择，接入成熟的邮箱管理工具，把主要精力集中在扩展交互、流程编排和稳定性优化上。如果后续想要降低用户的使用成本，可以考虑把管理工具接入服务器。

从结果看，这个取舍是值得的。它让我更快把一个可用版本做出来，也让后续迭代重点更清晰。

真实反馈推动了这个项目持续进化

这个项目不是做完就结束了。发布之后，我收到了不少来自社区用户的真实反馈，包括步骤超时、页面识别失败 、验证码提取异常、多轮执行卡死、标签未同步、某些环境下流程分支与预期不一致，这些反馈对我帮助很大。

因为很多问题在自己的机器上未必能复现，但一旦进入真实用户环境，兼容性问题就会集中出现。

也正是在这个过程中，我逐渐把项目从“自己能用”推进到了“更多人也能稳定使用”的状态。

对我来说，这其实是整个项目里最有价值的一部分。

最后

🔗GitHub：

如果你对这个项目感兴趣，欢迎看看代码，也欢迎提 Issue 或建议。

我会继续在真实使用反馈的基础上迭代这个项目。

这个项目对我来说，意义不只是把流程跑通。更重要的是，我把一个原本分散、脆弱、需要频繁人工介入的过程，整理成了一个可视化、可管理、可复用、可持续迭代的工具。

从邮箱池管理，到验证码轮询，再到流程结束后的标签回写，整个链路终于有了清晰状态和闭环。

这也是我最近做得最投入、也最有成就感的一个开源项目。