2026 Chrome Email Verification API 能替代注册验证邮件吗？开发者怎么测

不能完全替代：截至 2026 年 10 月 23 日，Chrome Email Verification API 在适用条件满足时，可以证明用户控制某个邮箱账号，但不能证明验证邮件已发送或送达。本周建议把它作为渐进增强接入，保留传统邮件回退，并分别验收令牌校验与实际收件。

这篇文章适合为自家注册或账号恢复流程接入 API 的开发者，也适合负责注册验收的 QA 工程师。评估验证体验的产品工程团队，也可以据此判断哪些场景仍须保留邮件流程。

最后更新于 2026 年 10 月 23 日。试验范围、令牌流程与服务端校验要求，已对照 Chrome 官方 API 文档、Chrome 服务端实现指南、Chrome 2026 年 10 月更新说明、WICG 浏览器 API 草案及 IETF 邮箱验证协议草案核对。

先按验证目标划分三个里程碑

“邮箱验证”可能指三种不同结果，验收时要分开记录：

• 邮箱控制权：服务端成功校验令牌后，可据令牌声明确认用户控制该邮箱。它不表示用户收到了你发送的邮件。
• 应用注册状态：账号是否创建、是否开放功能，仍由产品的业务规则决定。API 验证通过不必然等于注册流程的所有环节完成。
• 邮件发送与实际收件：欢迎信、密码重置通知或传统验证邮件是否发出、是否到达收件箱，是独立的邮件链路验收。这项验证机制不通过发送邮件来验证邮箱，也不能证明邮件可送达。

因此，判断重点不是“新 API 还是旧邮件”二选一。若目标只是确认用户控制邮箱，且相关浏览器、邮箱提供方和用户授权条件都满足，可以让令牌路径减少跳转；若产品仍需发送通知，或令牌路径不适用，就要保留邮件流程。

Email Verification Token 能证明什么

Chrome Email Verification API 由网站、浏览器和邮箱提供方共同参与。网站在表单中声明邮箱输入框，并提供带 autocomplete="email-verification-token" 的隐藏字段和服务端生成的 nonce。浏览器在满足条件时向参与的邮箱提供方请求令牌，再将令牌随表单提交。

收到令牌后，服务端必须验证签名及相关声明，核对令牌中的邮箱与表单提交值，并检查令牌绑定的站点来源和当前请求的 nonce。还应按当前实现要求检查时间相关声明，拒绝过期或不符合预期的令牌。不能只解码令牌，或仅凭请求中存在 token 就放行。服务端验证方还需要正确处理密钥查询：令牌可能不包含 kid，实现不能把缺少该字段直接当作无效签名。

令牌校验失败、来源不匹配、nonce 不符或时间声明无效时，不应放行令牌路径。每次请求使用独立且不可预测的 nonce，并将它与服务端会话绑定，可降低令牌被重放或跨请求复用的风险。协议草案仍是工作文档，不能写成已经确立的跨浏览器 Web 标准；WICG 草案和 IETF Internet-Draft 均应按提案或草案理解。

适用范围取决于浏览器、邮箱与授权

截至本文核对日期，Chrome 官方将该功能列为 Origin Trial：桌面 Chrome 150 至 160，Android Chrome 154 至 160。在试验延期前取得的旧令牌将于 2026 年 11 月 17 日到期；已登记的团队应检查令牌状态，必要时续期并重新部署。试验状态和支持范围可能变化，发布前应重新核对官方页面。

即使浏览器版本符合，也不保证用户每次都能取得令牌。邮箱域名需要发现参与的签发方，用户通常需要在当前浏览器配置文件中登录相应邮箱账号，并完成必要的授权交互。用户拒绝授权、邮箱提供方不支持、浏览器不支持，或令牌请求未完成，都可能让表单没有可用令牌。

Chrome 2026 年 10 月的更新还说明，试验期间的实现可能继续调整。例如，Chrome 154 起支持 Android 和第三方 Origin Trial，但第三方试验登记源与签发方须符合文档规定的同站条件；验证方和邮箱提供方也要留意更新后的请求头及令牌处理要求。不要把这些阶段性范围推断为所有浏览器都已支持。

失败路径应回到邮件确认流程

Chrome 官方建议采用渐进增强：浏览器或邮箱提供方不适用、没有可用令牌，或服务端校验失败时，网站继续提供既有邮件确认流程。测试不能只覆盖令牌成功的浏览器和账号，还要确认令牌缺失、无效及用户未授权时，注册仍能通过邮件路径完成。

两种方式的验收证据并不相同：

• 令牌路径减少用户离开页面取邮件的需要。它证明邮箱控制权，但依赖浏览器试验功能、参与的邮箱提供方、账号会话及授权。
• 邮件路径要求用户打开验证码或验证链接。测试人员可以检查邮件实际是否到达、正文是否正确，以及验证码或链接能否完成后续操作；同时要考虑发送延迟、垃圾邮件判定和重复请求导致的旧码失效。
• 业务通知路径仍需单独检查。令牌成功不代表欢迎信、密码重置通知等邮件已发送或已到达。

可以按三个里程碑安排验收：开发阶段检查令牌的有效与无效分支；预发阶段确认所有不适用情形能够回退；上线验收分别记录身份验证结果和邮件收件结果。这样不会因为一次注册成功，就误判整个邮件链路也已通过。

服务端校验按这些断言拆分

以下清单只针对自家产品或获授权的测试环境。将每项结果记录为独立断言，不要只看页面最后是否显示“注册成功”。

• [ ] 每次验证请求都生成新的 nonce，并确认服务端将其绑定到当前会话。
• [ ] 使用有效令牌走成功路径；验证签名、邮箱声明、站点来源和 nonce，并检查当前实现要求的时间声明。
• [ ] 删除令牌后提交，确认系统转入既有邮件确认流程，而不是默认放行或返回无法恢复的错误。
• [ ] 篡改令牌或关键声明后提交，确认令牌路径被拒绝，并按产品规则进入回退处理。
• [ ] 使用错误来源、不匹配的 nonce、过期令牌或重复使用的令牌，确认服务端不会错误放行。
• [ ] 在没有邮箱账号会话、用户未授权或浏览器不提供令牌时提交，确认邮件回退可继续完成。
• [ ] 实际打开回退邮件，核对主题、正文、验证码或链接，并完成验证码输入或链接验证。
• [ ] 另行检查欢迎信、账号恢复通知等业务邮件；不要将身份验证成功当作这些邮件的发送或收件证据。

邮件回退仍要检查收件箱

要测。如果产品承诺发送验证邮件、欢迎信或账号恢复邮件，就要实际检查邮件并完成对应操作。令牌通过只能作为邮箱控制权验证的证据，不能替代收件箱验收。

回退测试还要把容易混淆的结果拆开：发件系统接受请求，不等于邮件已经到达；预发与生产可能使用不同的发送配置；重复发送可能令旧验证码失效；共用测试地址则可能造成账号与邮件数据串扰。建议给每次测试设置可辨认的用例标记，将发件日志与实际收件结果分开记录。需要排查测试邮件的收件路径时，可参考收件路径诊断指南。

测试数据也应尽量使用合成资料，避免把真实员工地址、个人信息或长期有效的账号恢复链接放进共享环境。需要梳理数据处理边界时，可参阅隐私政策。

最终发布记录应保留两项独立结论：令牌校验通过，表示邮箱控制权验证路径可用；测试邮件被实际收取并完成操作，表示这次邮件回退链路可用。若团队只需临时检查传统邮件回退，ResendBox 的临时收件功能可作为自家产品测试的一种方案；官网说明该功能无需注册即可使用，但一次测试收件结果不能证明 Chrome API 的兼容范围，也不能代表生产环境送达表现。可从 ResendBox 收件页开始测试；银行、政务、重要账号找回或需要长期收信的流程，仍应使用团队可持续控制的邮箱。