reCAPTCHA v2和v3区别：交互、评分、后端校验与选型

两者的根本区别在于“由谁来做最终判断”。

reCAPTCHA v2：用户需要参与，比如勾选复选框，可疑时还要完成图片挑战。Google 的校验结果只有通过和不通过两种。
reCAPTCHA v3：用户完全无感，页面不会弹出挑战。Google 只返回一个 0.0–1.0 的风险分数和一个 action 标签，拦不拦截由你的后端决定。

所以换版本不只是换一段前端代码。后端逻辑、日志、阈值调优，以及自动化测试时要准备的参数，都会跟着变。

一张表看清核心差异

维度	reCAPTCHA v2	reCAPTCHA v3
用户看到什么	Checkbox“我不是机器人”，或 Invisible 徽章；可疑时弹图片挑战	只有徽章，不弹任何挑战
判定方式	二值：`success` 为 true 或 false	评分：`score` 从 0.0（像机器人）到 1.0（像人）
谁决定放行	Google 的挑战结果基本决定了是否通过	你的后端按阈值决定放行、复核或加验证
action 标签	没有	有，如 `login`、`checkout`，后端需要比对
部署范围	一般只放在具体表单上	Google 建议多页面部署，为风险模型提供上下文
token	2 分钟有效，只能校验一次	同样是 2 分钟、只能校验一次，建议在提交时才获取

前端：v2 有两种形态，v3 只有一种

v2 分为两种：

Checkbox：用户主动点击复选框。风险低时直接通过，存疑时弹出图片点选挑战。
Invisible：不显示复选框，验证绑定在按钮或表单提交上。大多数用户察觉不到，只有被判为可疑的流量才会看到图片挑战。

注意，Invisible v2 仍然属于 v2。它会出挑战，结果也是二值，和 v3 不是一回事。很多人看到页面上只有右下角的徽章就以为是 v3，这种判断并不可靠。

v3 在后台执行 JavaScript，无论风险高低都不会给用户展示图片挑战。前端通过 grecaptcha.execute(siteKey, {action: 'login'}) 获取 token，然后把 token 和表单一起提交给后端。

另外，v2 和 v3 使用的密钥类型不同，一种版本的 site key 不能直接拿去另一种版本使用。切换版本时要重新申请密钥。

后端：v3 把决策权交给你

两个版本都是由后端把前端提交的 token 发到 Google 的 siteverify 接口校验，但拿到结果后的处理方式差别很大。

v2：返回结果中的重点是 success，再检查 hostname 和 challenge_ts 是否合理即可。挑战已经在前端完成，后端的判断很简单。

v3：success: true 只说明 token 是有效的，并不代表“这是真人”。你还需要做两件事：

比对 action。返回的 action 必须和这个接口预期的一致，这样可以防止在首页拿到的 token 被挪到登录接口使用。
根据 score 决定处理方式。Google 不公开评分算法，也没有统一的标准阈值。0.5 是常见的起点，但具体数值需要根据你自己的流量来调整。

下面是一段示意性质的伪代码，只用来说明判断顺序，不能直接运行：

result = siteverify(secret, token)

if not result.success:           -> 拒绝（token 无效、过期或已被使用）
if result.hostname 不是本站:      -> 拒绝
if result.action != "login":     -> 拒绝（action 不匹配）

if result.score >= 0.7:          -> 正常放行
elif result.score >= 0.3:        -> 追加验证（如 v2 挑战、短信/邮件验证、人工审核）
else:                            -> 拒绝或限流

这里的 0.7 和 0.3 只是示例。比较稳妥的做法是：上线初期只记录分数、不做拦截，观察一段时间的分数分布、误伤投诉和攻击情况，再确定每个 action 的阈值。登录、下单这类敏感操作可以设得严一些，浏览类页面可以放宽。

reCAPTCHA v2 二值校验与 v3 评分分档决策的后端流程对比

token 规则：两个版本相同，但 v3 更容易因为时机出错

两个版本的 token 都是 2 分钟内有效，并且只能在 siteverify 成功校验一次。第二次提交同一个 token 会失败。

v3 常见的错误是在页面加载时就调用 execute，等用户填完表单点提交时，token 已经过期。Google 的建议是在用户触发关键操作时再获取 token。v2 Checkbox 也有类似情况：用户勾选后停留太久才提交，同样会过期，需要重置组件。

超出免费配额时，两者表现不同

根据 Google FAQ 的说明，标准版（非 Enterprise）有免费调用量和 QPS 上限，文档给出的数字是每月 100 万次、1,000 QPS。实际额度以你项目当前的条款和控制台为准。超出配额后：

v2：前端组件会直接向用户显示错误，问题容易被发现。
v3：前端没有任何变化，但 siteverify 可能返回一个固定分数（例如 0.9），并附带超额相关的错误信息。

v3 的这种表现很危险。如果后端只看 score，超额期间所有请求都会拿到高分，拦截实际上已经失效。建议在后端检查返回里的错误字段，并对“分数分布突然变成单一值”设置告警。

怎么选

只想防表单滥用，可以接受少量用户摩擦：用 v2 Checkbox 最简单，后端逻辑最少。
不想打扰用户，但仍希望可疑时出挑战：用 Invisible v2。
重视转化体验，并且有能力做风控决策：用 v3。前提是团队愿意维护阈值、日志和二次验证流程，否则拿到分数也用不起来。
既要体验又怕误伤：v3 + v2 组合。先用 v3 评分，高分直接放行，中间分数再弹出 v2 挑战或走其他验证，低分拒绝。这样绝大多数正常用户无感，也不会因为只看分数而把真实用户直接挡掉。注意两个版本要分别申请密钥。

如果你的业务已经涉及 Enterprise 版，它的接入和计费方式与标准版不同，不要直接套用本文的配额说明。

自动化与测试：先识别版本，再准备参数

对于在自有或已授权系统上做回归测试、RPA 或公开数据采集的团队，搞错版本是任务失败最常见的原因之一。可以按以下几点判断：

页面上有可见的复选框：v2 Checkbox。
只有徽章，但点击提交时可能弹出图片挑战，元素上常见 data-size="invisible"：Invisible v2。
脚本加载地址带有 render=站点key 参数，并在提交前调用 grecaptcha.execute 且传入 action：v3。
加载的是 enterprise 相关脚本：Enterprise。它不等同于标准 v3，需要单独处理。

不同版本需要的输入也不一样：

v2：通常只需要 sitekey 和页面 URL，目标是拿到填入 g-recaptcha-response 的 token。
v3：除了 sitekey 和 URL，还要指定和页面实际调用一致的 action，并了解目标后端要求的最低分数。action 填错，或者分数低于对方阈值，拿到的 token 仍会被对方后端静默拒绝，页面上往往看不到明确的报错。

因此排查时要把三个结果分开看：识别服务返回了 token、目标站点接受了这个 token、业务流程真正完成。只拿到 token 不代表任务成功。也不要把所有失败都归咎于 IP，token 过期、重复提交、action 不匹配、版本判断错误同样常见。

如果是 QA 回归自家系统，Google FAQ 为 v2 提供了专门的测试用 key，可以先用它验证流程是否跑通，不必接入外部服务。需要在真实联调或规模化任务中处理 v2、v3 或 Enterprise 时，NexCaptcha 通过统一的任务接口（createTask 提交任务、getTaskResult 取结果）支持这几类 reCAPTCHA。具体任务类型和字段请以首页说明为准，并用小流量先验证目标站点的实际接受率。完整的提交、轮询和结果注入流程可以参考 Python 验证码识别 API 接入，reCAPTCHA 的整体工作原理见这篇说明。

小结

v2 的特点是“用户做题，Google 给结果”，接入简单，但会给用户带来摩擦；v3 的特点是“Google 打分，你来决策”，体验好，但需要你自己维护阈值、action 校验和超额监控。选型时先想清楚你的团队能否承担后端决策的工作，再考虑用户体验。做自动化处理时，先确认页面用的是哪个版本，再准备对应参数。