最近基于自己的实际需求,我做了一个 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,同时也兼容多种临时邮箱提供商能力,方便根据实际场景切换不同来源。
整个流程完成后,插件会自动给对应邮箱打上标签。下次运行时,优先从未打标签的邮箱中继续处理。
这样一方面,邮箱获取、验证码等待和账号切换被整合到了同一个界面里,使用过程更顺畅。另一方面,通过“已注册”这类标签管理,可以快速筛选未处理邮箱,实现状态闭环,减少遗漏和重复操作。
使用教程
安装本扩展
打开 github 仓库,clone 或下载 zip 到本地
打开
chrome://extensions/开启 “开发者模式”
点击 “加载已解压的扩展程序”
选择当前目录
hotmail-register-extension
部署并启动 Outlook Email 服务
使用仓库:assast/outlookEmail,并按照 readme 指示成功部署
确保你已经可以通过浏览器访问它的后台页面和 API(** 一定要先从浏览器打开一次前端!** 否则无法给邮箱打标签)
获取 Outlook Email 的 API key 和 API URL
API URL 就是 Outlook Email 前端地址
API key 是打开 Outlook Email 前端,点击右上角设置,有一个 “对外 API”,点击生成即可
配置插件
- 在插件侧边栏填写 API URL、API key、CPA URL、管理密钥、默认登录密码
开始运行
Q&A
1.hotmail 邮箱从哪里来?
可以直接购买,一般 2-6 分一个,买 100 个也不超过 10 元,对于个人使用已经足够了
如果有 hotmail 邮箱,可以参考佬友分享的方式: hotmail 插件注册机(90%成功率,两分钟一个) 点击这个项目里的 GitHub 仓库,仓库里有个 “别名邮箱生成”,可以一键生成别名邮箱。生成之后再导入 Outlook Email 里。

注册机仓库文件
- 第八步弹出 add-phone 进行不下去了?
这是 ip / 邮箱问题,hotmail 也小概率会出现。可以考虑放弃这个邮箱,标记为已注册,开始下一个
- 卡在第二步,一直在 outh 页面,出不来注册页面,无法继续推进
这通常与节点环境有关,可以优先检查当前网络环境与页面状态。
- 已经可以拉取邮箱,但标签没有正常同步 通常是因为邮箱管理端前端页面没有先在浏览器中打开,导致相关状态未建立。 按文档提示先访问一次前端页面即可。
测试结果:

插件运行成功展示

Outlook Email标签
开发中遇到的坑
很多人看到自动化扩展,第一反应会觉得无非是“自动点按钮”。但真正做下来之后,我发现最麻烦的部分其实在于流程稳定性。
这个项目涉及“CPA 面板、OAuth 页面、注册页、验证码获取、授权回调、标签同步”多个阶段。每个阶段都可能因为“页面语言、节点环境、邮箱类型、邮箱格式、页面结构变化、跳转时机差异、旧状态污染新一轮流程”这些因素导致失败。
所以这个项目真正的工作量,主要花在“流程状态识别、异常分支兼容、验证码轮询与提取策略、多轮任务重置与恢复、标签同步与日志可观测性”这些方面。
也正因为如此,我更愿意把它看成一个带状态推进和异常恢复能力的自动化系统,而不是一个一次性脚本。
在测试和维护过程中,我遇到过不少很真实的问题,这里也记录一下:
页面语言差异导致识别失败 最初很多识别逻辑是基于英文页面写的,但真实用户环境里存在中文页面,结果就是某些步骤会直接卡住。后面我补充了多语言兼容逻辑,降低了这类问题的出现概率。
多轮执行时页面状态没有正确重置 首轮成功后,下一轮流程可能仍然停留在旧页面状态,导致无法正常获取新的入口或继续推进。这个问题后来通过刷新与重置逻辑进行了修复。
验证码邮件格式并不统一 不同邮箱来源、不同阶段的邮件格式差异很大。有些验证码在标题里,有些在正文里,有些还会因为历史邮件干扰而误读。后续我调整了轮询与提取策略,并给是否读过邮件打了标签,减少了重复读取旧邮件的问题。
标签同步依赖前端访问状态 有一个非常容易忽略的细节是,如果邮箱管理端的前端页面从未在浏览器里打开过,就可能出现“能拉邮箱但不能打标签”的情况。这个问题后来也补充到了文档和提示信息里。
为什么我选择接入现成邮箱管理工具
一开始我也想过直接对接邮箱底层接口,但评估之后,我发现这样会把复杂度迅速拉高,主要考虑到、认证体系、Token 生命周期、后台管理、多邮箱来源统一抽象。这在开发中需要额外投入不少精力,相当于是重复造轮子。
所以我最后做了更现实的工程选择,接入成熟的邮箱管理工具,把主要精力集中在扩展交互、流程编排和稳定性优化上。如果后续想要降低用户的使用成本,可以考虑把管理工具接入服务器。
从结果看,这个取舍是值得的。它让我更快把一个可用版本做出来,也让后续迭代重点更清晰。
真实反馈推动了这个项目持续进化
这个项目不是做完就结束了。发布之后,我收到了不少来自社区用户的真实反馈,包括步骤超时、页面识别失败 、验证码提取异常、多轮执行卡死、标签未同步、某些环境下流程分支与预期不一致,这些反馈对我帮助很大。
因为很多问题在自己的机器上未必能复现,但一旦进入真实用户环境,兼容性问题就会集中出现。
也正是在这个过程中,我逐渐把项目从“自己能用”推进到了“更多人也能稳定使用”的状态。
对我来说,这其实是整个项目里最有价值的一部分。
最后
🔗GitHub:
如果你对这个项目感兴趣,欢迎看看代码,也欢迎提 Issue 或建议。
我会继续在真实使用反馈的基础上迭代这个项目。
这个项目对我来说,意义不只是把流程跑通。更重要的是,我把一个原本分散、脆弱、需要频繁人工介入的过程,整理成了一个可视化、可管理、可复用、可持续迭代的工具。
从邮箱池管理,到验证码轮询,再到流程结束后的标签回写,整个链路终于有了清晰状态和闭环。
这也是我最近做得最投入、也最有成就感的一个开源项目。