reCAPTCHA v3 完全在后台运行，这使它从根本上区别于以往任何 CAPTCHA 方案。它没有谜题、没有复选框，也不会打断用户操作——相反，Google 的系统会持续观察用户行为，并为您网站上的每一次交互分配一个风险评分。
当页面在启用 recaptcha v3 javascript 库的情况下加载时，Google 会开始被动收集广泛的行为和环境信号。这些信号包括：
所有这些信号都会输入 Google 的机器学习模型，该模型已经基于大量真人流量和机器人流量进行了训练。最终结果是一个 0.0 到 1.0 之间的评分，每当受保护操作被触发时，这个评分都会返回给您的 backend。
注意：在免费层级中，reCAPTCHA v3 只提供四个离散的评分等级（0.1、0.3、0.7 和 0.9）。完整的 11 级范围（0.0–1.0）则需要将计费账户绑定到您的 Google Cloud 项目。
下表展示了社区中常见的评分解释方式。Google 官方建议以 0.5 作为初始阈值，并根据您自己的流量模式进行调整——下面这些细分区间是开发者的通行约定，并不是 Google 严格定义的官方标准：
如果 reCAPTCHA v3 给某个用户分配了较低评分，通常最好不要立刻封禁。相反，您应将该会话视为高风险，并触发升级校验，例如可视化 CAPTCHA、邮箱验证、一次性密码或多因素身份验证。对于登录、注册或结账这类敏感操作，您还可以放慢请求处理速度、限制重复尝试次数，或在需要时转交人工审核。这种做法有助于减少误判，保护合法用户，并让您在安全性与用户体验之间获得更灵活的平衡。
recaptcha v3 google 的一个关键架构特性是 action 参数。每次调用 grecaptcha.execute() 时，您都要传入一个命名的 action 字符串——例如 login、register、checkout 或 contact_submit。这个标签会：
这意味着，您的 backend 不仅可以验证是否返回了评分，还可以验证这个评分是否对应于您想要保护的确切用户操作——从而防止 token 回收攻击，即机器人先在低风险页面生成 token，再将其重放到高风险页面上。
一旦 grecaptcha.execute() 被触发，它会返回一个一次性 token，其有效期恰好为两分钟。您的 frontend 必须立刻将该 token 传递给 backend，而 backend 必须在时间窗口过期前通过 siteverify endpoint 对其进行验证。Token 不能重复使用——同一个 token 第二次验证时会因 timeout-or-duplicate 错误代码而失败。这种设计确保每个受保护操作都绑定到一份最新且唯一的行为快照。
理解这个系统的边界非常重要：
这种设计理念——只评分、不强制执行——为开发者提供了精细控制，但也意味着，您的机器人防护效果最终取决于您围绕评分所构建的逻辑质量。
不同于 reCAPTCHA v2 只在某一个时间点检查用户（即点击复选框的那一刻），recaptcha version 3 可以在整个会话期间多次调用——例如页面加载时、表单获得焦点时和提交时。每次调用都会生成一个独立评分，反映截至当时为止的行为。这使您能够构建分层验证：如果页面加载时是低风险评分，但表单提交时变成可疑评分，就可以在会话中途触发升级校验，同时又不会无缘无故向用户展示 CAPTCHA。
理解这两个版本之间的权衡，有助于您为合适的页面选择合适的工具，并避免部署一种不是让用户感到沮丧、就是在防护上留下空隙的方案。
reCAPTCHA v2 采用基于 challenge 的模型。当系统怀疑访客不是人类时，它会打断用户流程并要求其证明自己是人类——要么点击 “I'm not a robot” 复选框（随后会评估鼠标移动和时间节奏），要么完成图像识别谜题。结果是二元的：用户通过或失败。
reCAPTCHA v3 则完全取消了 challenge。它不会停下来向用户提问，而是在整个页面会话期间静默观察行为，并返回一个 0.0 到 1.0 的连续风险评分。之后由您的应用决定如何处理这个评分——而这一决策层完全由您控制。
对于 v2，逻辑很直接：Google 决定是否需要 challenge，并将其展示出来。您会收到一个二元 token——有效或无效——然后由 backend 据此采取行动。这种简洁性是它在低复杂度部署中的优势，但也意味着您几乎无法知道一个请求到底有多么可疑。
对于 v3，精细度取代了简洁性。0.9 的评分和 0.3 的评分在技术验证上都算通过——但它们传达的是完全不同的访客画像。您的应用可以对两者采取不同响应：对 0.9 给予完全访问权限，对 0.4 要求邮箱确认，或对 0.1 进行静默封禁。
reCAPTCHA v2 中的图像谜题长期以来一直被批评为一种障碍，尤其是对于视障用户、认知障碍用户，或者难以辨认扭曲文字和模糊图像分类的低识字用户而言更是如此。音频替代方案往往同样困难。reCAPTCHA v3 invisible 模式则完全绕开了这个问题——残障用户不会比其他人承受更多额外阻碍。
不过，v3 也引入了它自己的一种间接不可访问性：如果某一类用户的行为信号（例如仅使用键盘导航的人，或会产生非典型交互模式的辅助技术使用者）持续得到较低评分，那么这些用户可能会在没有任何申诉方式、也无法自证为真人的情况下被静默惩罚。因此，对于包容性部署来说，阈值调优和 fallback 策略非常重要。
在以下情况下选择 reCAPTCHA v2：
在以下情况下选择 reCAPTCHA v3：
还值得注意的是，这两个版本并非互斥。常见的一种部署模式是将 v3 作为主层运行，并仅在 v3 返回低评分时才触发v2 challenge 作为 fallback。
recaptcha v3 invisible 运行方式最直接的好处是，用户根本不会察觉它的存在。没有需要眯着眼去辨认的图片网格，没有音频谜题，也没有需要在手机屏幕上费劲寻找的复选框。整个防护过程都在后台完成。
这对转化率很重要。用户旅程中任何一步的阻碍——尤其是在登录、注册或结账时——都会直接影响流失率。通过消除 challenge 带来的打断，google recaptcha v3 能让合法用户顺畅完成受保护操作。
不过，这种 UX 权衡并不是零成本的。由于 v3 依赖行为画像，它可能会静默地将合法用户判定为可疑——例如移动速度异常快的高级用户、使用 VPN 的注重隐私用户，或来自意外地理区域的访客。如果您的阈值设得过于激进，真实客户就可能在毫无解释的情况下被悄悄拦截。推荐的起始阈值是 0.5，但应根据您自己的流量模式进行调整。
集成 reCAPTCHA v3 包括三个连续阶段：注册密钥、在 frontend 连接 recaptcha v3 javascript，以及在 backend 验证 token。下面是完整流程。
在编写任何代码之前，您需要先获取凭据。
在每个您想保护的页面上，通过将以下标签添加到 HTML 的 <head> 中来加载 recaptcha v3 api 脚本，并将 YOUR_SITE_KEY 替换为您的真实密钥：
<script src="https://www.google.com/recaptcha/api.js?render=YOUR_SITE_KEY"></script>这一段代码会初始化 recaptcha v3 google 引擎，并开始在后台被动收集行为信号——不会向用户显示任何 widget。
与 recaptcha v2 不同，您不需要渲染 widget。相反，您应在用户触发受保护操作时以编程方式调用 grecaptcha.execute()。
方案 A —— 带 data-attributes 的按钮（适用于简单表单）：
<form id="login-form">
<!-- 您的表单字段 -->
<button
class="g-recaptcha"
data-sitekey="YOUR_SITE_KEY"
data-callback="onSubmit"
data-action="login"
type="button">
登录
</button>
</form>
<script>
function onSubmit(token) {
fetch("/api/login", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ recaptchaToken: token })
});
}
</script>方案 B —— 编程式执行（推荐用于 AJAX/API 流程）：
<script src="https://www.google.com/recaptcha/api.js?render=YOUR_SITE_KEY"></script>
<script>
async function submitLogin() {
const token = await new Promise((resolve) => {
grecaptcha.ready(() => {
grecaptcha.execute("YOUR_SITE_KEY", { action: "login" }).then(resolve);
});
});
// 立即发送 token —— 它会在 2 分钟后过期
await fetch("/api/login", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ recaptchaToken: token })
});
}
</script>关键规则：action 名称（例如 login、signup、checkout）必须与您的 backend 预期一致。这可以防止 token 在不同 endpoint 之间被重复使用。
您的服务器会接收 token，并在处理用户请求之前将其转发到 Google 的 siteverify endpoint。
Node.js 示例（包含错误处理）：
import express from "express";
const app = express();
app.use(express.json());
app.post("/api/login", async (req, res) => {
const token = req.body.recaptchaToken;
const params = new URLSearchParams();
params.set("secret", process.env.RECAPTCHA_SECRET);
params.set("response", token);
let data;
try {
const verifyResp = await fetch("https://www.google.com/recaptcha/api/siteverify", {
method: "POST",
headers: { "content-type": "application/x-www-form-urlencoded" },
body: params
});
data = await verifyResp.json();
} catch (err) {
console.error("reCAPTCHA verification network error:", err);
return res.status(503).json({ error: "verification_unavailable" });
}
// → 继续执行第 5 步
});注意：原生 fetch 在 Node.js 18+ 中可用。对于更早版本，请使用 node-fetch 或 axios。
Python（Flask ≥ 2.0）示例：
import os, requests
from flask import Flask, request, jsonify
app = Flask(__name__)
@app.post("/api/signup") # 需要 Flask >= 2.0
def signup():
token = request.json.get("recaptchaToken")
resp = requests.post(
"https://www.google.com/recaptcha/api/siteverify",
data={"secret": os.environ["RECAPTCHA_SECRET"], "response": token},
timeout=5
)
data = resp.json()
# → 继续执行第 5 步
if not data.get("success"):
return jsonify({"error": "recaptcha_failed"}), 403
return jsonify({"ok": True})Google 的 siteverify endpoint 会返回一个 JSON 响应。下面是成功响应的样子：
{
"success": true,
"score": 0.7,
"action": "login",
"challenge_ts": "2026-02-27T10:00:00Z",
"hostname": "example.com"
}您的 backend 必须按顺序检查三项内容：
siteverify 响应中可能包含一个 error-codes 数组。最重要、需要处理的错误包括：
不要将原始错误代码直接展示给终端用户——应在服务端记录日志，并显示类似“请重试”的通用消息。
在进入生产环境之前，请验证完整流程：
reCAPTCHA version 3 的行为画像模型带来了重要的隐私影响。该系统会收集鼠标移动、按键时序、浏览器指纹、IP 地址等数据——这些数据远远超出仅用于验证用户是否为真人所严格必需的范围。
对欧洲运营方而言，这尤其会带来 GDPR 风险。在一项引人注目的 2023 年执法行动中，法国数据保护机构（CNIL）对电动滑板车公司 Cityscoot 处以 €125,000 的罚款，原因是其存在多项 GDPR 违规行为——其中既包括过度收集地理位置数据（每 30 秒跟踪一次滑板车），也包括在未获得适当用户同意的情况下部署 Google reCAPTCHA。CNIL 裁定，reCAPTCHA 对用户终端数据的访问需要依据法国《数据保护法》第 82 条事先取得同意——它并不只是一个被动的安全 widget。如果您在 GDPR 框架下运营，那么在部署 google recaptcha v3 之前，与 Google 签署适当的 Data Processing Agreement 并获得相应的用户同意是必要的。
CapMonster Cloud 是一项由 AI 驱动的 CAPTCHA 识别与自动化服务，支持 reCAPTCHA v2、v3 和 Enterprise，以及许多其他 CAPTCHA 类型。对于开发和测试团队来说，它提供了一种无需人工干预即可自动化与受 reCAPTCHA 保护表单交互的方式——这对集成测试、自动化监控流水线，或那些 CAPTCHA 处理成为瓶颈的合法抓取工作流都很有用。
在 using recaptcha v3 的场景中，CapMonster Cloud 充当 solver API：给定目标 URL 和 site key，它会返回一个有效的 reCAPTCHA token，这个 token 可以像真实浏览器那样提交到受保护的 endpoint。
创建任务：
POST
https://api.capmonster.cloud/createTask请求
{
"clientKey": "API_KEY",
"task": {
"type": "RecaptchaV3TaskProxyless",
"websiteURL": "https://lessons.zennolab.com/captchas/recaptcha/v3.php?level=beta",
"websiteKey": "6Le0xVgUAAAAAIt20XEB4rVhYOODgTl00d8juDob",
"isEnterprise": false,
"minScore": 0.7,
"pageAction": "myverify"
}
}响应
{
"errorId":0,
"taskId":407533072
}
获取任务结果：
POST
https://api.capmonster.cloud/getTaskResult请求
{
"clientKey":"API_KEY",
"taskId": 407533072
}响应
{
"errorId":0,
"status":"ready",
"solution": {
"gRecaptchaResponse":"3AHJ_VuvYIBNBW5yyv0zRYJ75VkOKvhKj9_xGBJKnQimF72rfoq3Iy-DyGHMwLAo6a3"
}
}详细的 API 文档和集成示例可在 capmonster.cloud 上查看。
reCAPTCHA v3 在平衡机器人防护与用户体验方面代表了一项重要进步。它将验证过程完全移到后台，并用细致的风险评分取代二元的 pass/fail 逻辑，使 recaptcha google v3 能让安全团队按比例采取措施——阻止明显的机器人、对可疑会话提升阻碍级别，同时让合法用户完全不受打扰。
这种权衡是真实存在的：评分解释需要 backend 投入，阈值调优需要时间，而在 GDPR 框架下，其隐私足迹也不可忽视。不过，对于大多数生产环境 Web 应用——尤其是那些在登录、注册或结账环节中，任何阻碍都会带来转化损失的应用来说——从 v2 升级到 v3 是非常值得的。
准备好在您的网站上部署 reCAPTCHA v3，或者围绕它自动化您的测试流水线了吗？访问 CapMonster Cloud，探索适用于 reCAPTCHA v3、v2 和 Enterprise 的 AI 驱动 CAPTCHA 解决方案——提供完整 API 文档和集成示例，帮助您在几分钟内快速上手。
