站里表单接人机验证，不弹图片只按风险决定要不要勾选框，后端还要验什么

给网站表单加人机验证，很多人还停留在弹图片、挑红绿灯的印象里。现在更常见的做法是按风险放行：正常访客一路通过，风险偏高的请求才会看到勾选框。于是问题分成两半，前端怎么少打扰人，以及验证通过之后，后端还要验什么。下面从判定方式、形态选择、服务端校验和失败返回四步展开，最后附几则常见问题。

不弹图片时，验证靠什么判定访客是不是人

以 Cloudflare Turnstile 的公开说明为例，它把自己描述为免 CAPTCHA、隐私取向的机器人防护替代方案，判定依靠浏览器里运行的客户端安全挑战，观察环境特征与行为信号，而不是靠一道肉眼题目去考人。它的 Managed 形态会按访客风险水平自动决定是否需要显示勾选框：多数低风险访客完全无感，风险偏高时才出现一个复选框点一下。

这也解释了为什么页面看起来什么都没做就通过了。对表单来说，前端拿到的是风险判定结果，后端的职责并没有减少，只是换了校验对象。

托管、非交互、不可见三种形态分别适合哪些表单

差别在于访客被要求的程度。托管形态由平台自行决定要不要出交互；非交互形态默认无感，只在风险升高时给出一次挑战；不可见形态全程不出现控件，判定完全在后台完成，因此对失败处理的要求更高。

选择时可以先看表单被批量提交的历史，以及业务能接受的打扰程度。登录页更在意流畅，不可见更合适；注册页一旦被脚本刷，后果比较重，托管形态的弹性更好用。

令牌传到后端之后还要验什么

前端拿到的往往是一枚短时令牌，它只证明浏览器侧做过挑战，不证明提交这条数据的确实是浏览器。省掉服务器端的校验，等于门槛只装在门上，脚本仍可绕过页面直接调接口。

服务端这一步至少核对三项内容：令牌是否有效且没有被重复使用，令牌绑定的站点密钥与业务场景是否互相对应，来源域名与时间窗是否落在允许范围内。AnQiCMS 的表单可以接入 reCAPTCHA 一类的验证码，走的同样是前端取令牌、服务端再校验一遍、失败时给出返回的链路。把这条判定留在服务端，前端样式怎么改都不会直接影响防护强度。

校验失败时，接口该怎么回

失败返回要能被供应商处理，而不是笼统一句提交失败。常见做法是把情形分开：令牌无效、令牌过期、同一令牌重复提交、风险评分不足。返回里带上可识别的编码与简短说明，前端才好决定是重新触发挑战、提示稍后再试，还是直接拒绝。

同时按表单维度记录失败率与重复提交次数。失败率突然抬高，多半出在前端取令牌的环节；同一来源的重复提交集中，则更接近脚本行为，可以在接口层追加节流。

常见问题

问：勾选框一次都没出现，是不是验证没生效？ 答：未必。按风险放行的形态在低异常时段本来就可能全程无感。可以用明显的自动化请求自测一次，看是否被要求做挑战。

问：前端已经拦住了，后端还要再验一遍吗？ 答：要。前端拦截只覆盖真实浏览器那条路径，接口依然可能被直接调用，服务器端的令牌校验才是防线真正落地的位置。

问：不可见形态会不会让误拦更难处理？ 答：因为看不到控件，用户缺少重试入口，所以要把失败返回和人工申诉路径设计完整，再结合日志观察趋势。