CAPTCHA 类型：一个复选框究竟能说明什么

仅凭复选框、图片网格或不可见组件，无法可靠识别 CAPTCHA 类型。这些特征描述检查如何呈现，不会揭示其背后的全部机制，也不会说明网站的放行规则。应分别记录交互方式、文档说明的检查、部署位置与服务端决策。BotBrowser 提供基于 profile 的浏览器控制和代理配置，但不负责完成验证码、不揭示服务商的私有评分，也不保证网站接受某个会话。

摘要

• 复选框、图片任务和没有可见组件，描述的是交互方式；任何一个都不足以概括完整验证系统。
• 风险评分、工作量证明与认证证明（attestation）描述不同的检查或证据，可以与可见或不可见的交互并存。
• 浏览器生成的响应 token 仍须按服务商要求在服务端验证。应用授权是另外一个决策。
• 应根据文档明确的集成方式和所有者配置识别产品，而不是凭一张外观相似的挑战截图判断。
• 未知机制就记为未知。对于获授权的自动化任务，如果预期应用结果被挑战替代，应暂停依赖该结果的后续操作。

目录

• 沿四个独立维度分类 CAPTCHA
• 可见任务能够证明什么
• 后台检查可以评估什么
• 从 token 追到服务端决策
• 记录观察而不编造评分
• 按角色选择下一步
• 实践结论

沿四个独立维度分类 CAPTCHA

把“复选框”“不可见”“风险评分”和“工作量证明”列成四种相互竞争的类型，实际上混合了不同问题。复选框描述界面；不可见描述没有可见组件；评分描述某项服务返回的评估；工作量证明描述计算任务。选择其中一个标签，并不排除另外几个标签。

用四个字段代替一个通用类型。下表的值是分类选项，不是对线上服务商的测量结果。只有官方产品说明或部署所有者确认机制后，才填写机制字段。

维度	要回答的问题	可填写的值	该字段不能证明什么
交互	用户看见什么、执行什么操作？	复选框、图片任务、文字任务、没有可见组件	哪些私有输入参与了评估
机制	文档说明了什么检查或证据？	风险评估、计算证明、认证证明（attestation）	未公开的权重或本次请求的结果
位置	检查集成在哪里？	应用内嵌组件、插入式挑战页面	应用其余部分是否授权本次操作
决策	哪个组件接受什么结果？	服务商验证 token；网站执行自身策略	浏览器端成功是否等于业务成功

这些维度也能解释同一次访问中挑战为何改变外观。Google 文档说明，reCAPTCHA v2 复选框可以立即通过，也可以追加挑战。这是同一集成支持的分支，不证明网站更换了 CAPTCHA 服务商。事件时间线需要记录实际变化，不应根据每张画面重新猜一种产品类别。

相邻的采集中途出现 CAPTCHA 的排查路径负责挑战出现后的路由、浏览器会话和工作负载调查。分类回答更早的问题：画面证明了哪些事实，哪些事实需要服务商文档或网站所有者证据？它不会用一个产品标签替代事件调查。

主张范围与标签同样重要。“该产品公开说明会执行后台计算检查”属于产品层面的描述；“本次请求未通过该检查”属于一次执行的结论，需要对应证据。前者不能证明后者。支持记录应把产品能力与请求观察放在不同栏位。

可见任务能够证明什么

常见的复选框要求可见交互，但它在页面上的位置几乎不能说明完整验证过程。在 Google 的 reCAPTCHA 版本比较中，v2 复选框流程可以直接接受交互，也可能要求追加任务。因此，点击复选框既不是测量某个公开数值评分，也不能证明没有执行后台评估。

图片任务同样是一种交互格式。它的出现只能证明当前展示了图片任务。客户端观察者不能因此知道任务为何被选中、同一访客稍后是否会看到另一种格式，或完成任务后是否能满足独立的账号限制。记录显示的任务即可，不要编造选择规则。

文字输入等可见任务也适用相同分类。它们在操作要求、无障碍需求和潜在输入错误上存在差异。这些实际差异有助于应用所有者测试支持的用户流程，但不能作为给整个产品的安全质量排名的依据，也不能揭示选择任务时采用的后台证据。

“不可见”必须说明具体对象。Google 将 invisible reCAPTCHA v2 描述为无需点击复选框的集成，可通过按钮或 API 调用触发，疑似风险流量仍可能收到挑战。因此，没有初始复选框不等于承诺永远没有可见任务。

Cloudflare 的 Turnstile 组件模式包括 Managed、Non-Interactive 和 Invisible。Managed 可以选择非交互检查，也可能要求勾选复选框；Non-Interactive 显示组件但不要求交互；Invisible 执行时不显示组件。即使在同一产品中，“可见的框”和“必须点击”也是两件不同的事实。

hCaptcha 的不可见与被动模式说明提供了另一组区别。Invisible 去掉初始复选框，passive 行为则涉及是否呈现交互式挑战。文档说明可在适用的 Enterprise 产品中组合 invisible 和 passive 模式。不要把某一产品级别的选项泛化成所有账号和所有集成的保证。

可见观察	有依据的描述	没有依据的推断
显示复选框	集成提供复选框交互	一定存在公开风险评分
显示图片任务	流程呈现了图片任务	某个浏览器信号导致该任务
组件可见但没有要求点击	当前界面无需交互	没有执行浏览器检查
没有可见组件	在该状态下未观察到组件	不存在挑战集成或验证

无障碍与应用测试应记录实际要求的交互、文档明确的配置和对应页面状态。截图可以支持第一项事实，所有者配置可能证明第二项。两者都不能提供观察者无权读取的隐藏机制或服务商结论。清晰的截图不等于未公开评分模型的证据。

后台检查可以评估什么

风险评估与谜题答案不是同一种产物。Google 的 reCAPTCHA v3 文档说明，它为每个请求返回评分且不增加用户交互阻力，由网站决定后续动作；文档也说明 action 可为结果解释提供上下文。该响应模型并不意味着任意浏览器客户端都可以读取数值评分。

不能把评分的存在套到所有组件上。某项产品可以签发验证 token，却不通过标准集成暴露数值风险评分。反过来，基于评分的产品也可以为网站策略提供输入，再要求另一种验证。服务商结果、网站选择的响应与用户看到的交互，应分别记录。

工作量证明描述计算检查，而不是可见呈现形式。Turnstile 概述将工作量证明、空间证明和 Web API 探测列为其检查项目。多种机制可以在同一系统中参与判断。将这份清单改写成互斥的 CAPTCHA 产品，或认定不可见组件只采用其中一种机制，都不准确。

认证证明涉及在特定信任关系下签发或验证的证据。具体声明、签发者、先决条件与验证方取决于对应方案的文档。它不是“不可见”的同义词。如果服务商公开文档不能确认部署流程采用哪种认证证明，就保持该字段未指定，不要从视觉外观补全答案。

“评估什么”也需要边界。官方页面可能说明一类检查，但页面未列出其权重、阈值、组合方式或是否用于本次请求。客户端可以观察脚本执行或组件状态变化，但无法凭此还原完整服务端决策流程。浏览器控制台表达式不能把未公开的服务商评估变成可靠的本地诊断值。

浏览器特征可能成为输入，但不是通用解释。基于 profile 的浏览器控制可以改变文档明确的浏览器值，代理可以改变网络路由。这些变化都不能证明服务商评估了什么，也不能证明应用请求因这些输入而失败。保留浏览器配置有利于复现，但不要把配置差异改称为已经测得的 CAPTCHA 原因。

这也是为什么笼统的“人类或机器人”标签对支持事件过于粗糙。结果可能涉及 token 验证、上下文评估或独立应用规则。真正有用的问题是哪个组件返回了哪个文档明确的字段。宽泛标签会抹去区别，把操作方与应用团队引向缺乏证据的修复。

从 token 追到服务端决策

浏览器端完成回调只是较长流程中的一个事件。对于这里讨论的集成，网站必须先完成服务商要求的服务端验证，才能依赖响应 token；然后应用按自身规则决定是否允许操作。token 不是适用于站内所有路由的通用授权凭证。

阅读集成时，可以按以下职责顺序理解：浏览器执行配置好的客户端流程；应用收到响应 token；后端向服务商验证；后端检查与集成相关的返回字段；应用执行自身策略。这是逻辑责任划分，不是从真实客户部署中抓取的网络记录。

Google 的服务端验证文档要求后端请求包含 secret 与响应 token，并说明每个响应 token 的有效期为两分钟，且只能验证一次。secret 应留在服务端。浏览器日志包含 token，不证明后续验证成功；也不应把 token 本身贴到公开事件报告中。

对于 v3，官方指南要求网站验证 action，并结合上下文评估评分。这是所有者的集成职责。访客只看到表单提交失败，无法仅凭表单报错推断返回评分、策略配置或检查结果。应请求操作方关联具体请求，而不是把本地猜测的评分当成证据。

Cloudflare 的 Turnstile 服务端验证指南同样要求调用 Siteverify，只有客户端组件并不足够。token 在生成后 300 秒过期，按单次使用设计。重复使用检测采用最终一致性：在兑换状态传播之前，时间相近的多次验证可能成功。这不构成可重复使用 token 的契约。不要实现可重复使用的 token 缓存，也不要将组件完成事件视为后端验证成功。

阶段	负责组件能够取得的证据	成功仍然不能证明什么
客户端交互	组件状态、回调或文档明确的客户端错误	后端 token 验证已成功
服务商验证	实际 Siteverify 响应	应用允许该业务操作
应用策略	所有者配置的检查与请求日志	未来每次操作都会被接受
应用结果	预期的已认证结果或交易结果	另一个会话获得相同评估

内嵌组件与边缘挑战页面也处于请求路径的不同位置。Turnstile 可以嵌入网站，而不要求站点流量经过 Cloudflare CDN。Cloudflare Challenge Pages 则可能把预期资源响应替换为 HTML。现有按层定位采集被阻问题区分请求、传输与应用观察；响应正文改变时应采用那套调查，而不是认为所有与 Cloudflare 有关的检查都是同一种集成。

记录观察而不编造评分

有用的观察记录应说明每个字段如何得到。可见证据、官方产品能力和仅所有者可知的事实需要分开。下面是可复制的空白模板，不是服务商测试输出。把方括号替换为已核实的值，否则保留 unknown。

interaction_observed: [checkbox / image task / no visible widget / unknown]
product_identification: [documented integration or owner confirmation / unknown]
mechanism_documented: [official source and applicable mode / unknown]
placement_observed: [embedded / interstitial / unknown]
client_completion_observed: [yes / no / unknown]
backend_verification: [owner-confirmed result / unknown]
application_result: [expected result / refused / unknown]
correlation_reference: [redacted request reference / unavailable]

举一个推理场景：获授权的测试者看见登录表单中嵌入复选框，随后出现通用表单错误。这是一个假设案例。交互字段可以填写复选框，位置可以填写内嵌；没有集成细节，产品与机制仍未知；没有后端证据，验证结果仍未知。表单错误只能证明应用操作失败，不能证明某个评分或计算证明失败。

再假设网站所有者确认产品，并提供对应请求的脱敏验证失败响应。此时可依据证据更新后端字段。但除文档明确的响应字段之外，仍不能确认服务商为何得出结果，更不能确认更换浏览器就能修复。每个新增主张都需要自己的来源。

除了观察内容，还要记录观察范围。生产请求、官方测试 key 与本地模拟回调用途不同。模拟可以测试应用如何处理回调，却不能证明服务商行为。服务商测试设施可以按其声明的条件执行文档规定的集成路径，但不是常规生产风险评估的测量。应明确标注这些环境。

共享记录不应包含 secret、完整响应 token、cookie 或个人数据。最小关联引用与脱敏的文档明确错误，通常比完整浏览器转储更有用。所有者可按应用本身的访问与保留规则保存必要明细。收集更多数据，不会自动得到更准确的解释。

按角色选择下一步

网站所有者能够检查配置与后端验证记录，获授权的自动化操作方通常不能。应按这个访问边界选择下一步，而不是相信某种 CAPTCHA“类型”存在通用解法。分类的价值在于把问题交给正确组件的所有者，避免缺乏依据的本地试验。

角色与观察情况	下一项有界操作	不应得出的结论
网站所有者：客户端完成但应用拒绝	关联该请求的后端验证与应用策略记录	组件完成就保证获得许可
集成测试者：没有可见组件	按官方集成说明确认产品与配置模式	检查不存在或只采用认证证明
获授权操作方：预期数据变成挑战	暂停依赖该数据的提取，保留最小变化记录	服务商识别出了某个具体浏览器值
支持审阅者：只有截图	分类交互并请求缺少的所有者侧证据	已知隐藏评分或准确证明机制

BotBrowser 的自动化一致性参考说明基于 profile 的浏览器控制，包括明确列出的自动化相关表面；代理配置参考说明支持的路由配置。这些控制有助于描述可复现环境，但不验证服务商 token、不改变应用授权策略，也不证明不会触发挑战。两份参考都没有描述通用 CAPTCHA 解决方案。

对于现有集成，最后应提出一个能够回答的问题：第一个尚未核实的步骤由哪个组件负责？若后端结果不可得，继续解释复选框不会补出结果。若 token 验证成功但应用拒绝操作，应通过获认可的所有者调查应用决策。若第三方站点要求挑战，应采用其支持的人工或操作方恢复路径，不要把分类表当成继续提取数据的许可。

常见问题

不可见 CAPTCHA 就是 reCAPTCHA v3 吗？

不是。Invisible reCAPTCHA v2、reCAPTCHA v3、Turnstile Invisible 和 hCaptcha invisible 模式有不同的文档化集成模型。“不可见”描述呈现方式，不是通用评分接口。使用验证文档前，应先识别实际产品与模式。

复选框意味着服务测量了风险评分吗？

单独一个复选框不能证明网站可以读取数值评分。应查看部署产品的响应契约。即使服务返回评分，可见交互也不揭示该请求的具体数值。

同一系统可以同时使用工作量证明和可见组件吗？

可以，机制与交互模式未必互斥。Turnstile 文档同时说明计算检查和多种组件模式。这是产品层面的描述，不证明某个请求执行了全部公开机制；没有适用证据时，具体执行仍然未知。

来源

• Google：reCAPTCHA 版本
• Google：reCAPTCHA v3
• Google：验证用户响应
• Cloudflare：Turnstile
• Cloudflare：组件模式
• Cloudflare：服务端验证
• hCaptcha：不可见与被动模式
• BotBrowser：自动化一致性
• BotBrowser：代理配置

实践结论

描述实际观察到的交互，只补充文档明确的机制，定位集成位置；在所有者确认前，让后端决策保持未知。复选框不是评分，不可见不是认证证明，token 不是应用授权。从四字段分类开始，再向第一个尚未核实步骤的所有者请求继续操作所需的证据。