表单被机器人反复提交时，验证环节加在哪一步，需要什么前置配置

留言、联系这类表单被机器人反复提交时，验证环节应该加在“提交请求进入服务端校验”的那一步，而不是放在页面加载或字段填写阶段。站内表单接入的是 reCAPTCHA 验证码：前端在用户点击提交时取得一次性验证凭据，随表单数据一起送到后台，后台核对通过才继续写库；只靠页面里的输入限制拦不住直接构造请求的脚本。要在启用前准备的是后台验证设置里的两项凭据（网站密钥与通信密钥）以及总开关，凭据缺失时开关即使打开也不会真正校验。

先分清挡机器人与审内容

两件事解决的是不同风险，顺序不能颠倒。人机验证解决“这条请求是不是自动化脚本发的”，内容审核解决“这条内容能不能公开”。

机器人提交里既有纯垃圾广告，也有人机验证很容易过、但内容仍然违规的情况。只做前者，垃圾文案照样能出现在留言列表；只做后者，管理员要审核的条目数量不会被压下来。站内把这两层分开配置，正是为了让各自的处理范围清晰：验证在提交入口拦频率，敏感词过滤与关键词替换在内容层做处置。

接入的位置：提交前的最后一道

按实际流程，验证发生在三个位置之间：

1. 页面渲染时把公钥性质的站点凭据提供给表单脚本，用于唤起验证组件；
2. 用户提交时，验证组件产出凭据（token），随留言或表单数据一起发送；
3. 后台在处理写入之前，把凭据连同来源地址交给验证服务核对，核对不通过就不入库。

关键在第 3 步：校验放在写入之前，且由服务端完成。任何只在浏览器里做的判断，都可以被绕过页面直接提交而跳过。留言接口与普通表单接口都走同一类校验路径，新增表单时要把这一步当作必填项，而不是可选装饰。

启用前要准备什么

后台的验证设置需要三项就绪，缺一项都会表现为“开了但没效果”：

• 总开关：控制是否启用人机验证；
• 网站密钥：提供给前端组件使用；
• 通信密钥：供后台向验证服务核对时使用。

代码上的判定是“开关打开且两项凭据都非空”才执行校验，这也是最常见的故障原因：只填了网站密钥，前台能弹出验证组件、看着像已启用，但服务端不校验，垃圾提交依旧入库。配置完成后要用一条真实提交验证：凭据缺失或伪造时请求应被拒绝，正常提交能落到留言列表。

验证通过后仍要做内容过滤

频率被压下来之后，剩下的内容风险由内容安全设置承接：敏感词过滤决定命中词如何处置，关键词替换提供另一种处理方式——不是简单拦掉，而是按设定替换。两者都在写入前后作用于内容本身，与人机验证不在同一层。

评论侧的反垃圾属于另一条通道，处理的是评论而非留言表单，配置位置不同，不要把两处的开关当成一处。若还想减少无意义提交，可在业务层加频率限制与字段校验，把明显不合法的数据挡在验证之前，降低核对次数。

常见问题

验证组件弹出来了，是不是就说明配置生效了？ 不能这样判断。前台能弹出只说明网站密钥可用，服务端是否核对取决于通信密钥是否也已填好、开关是否打开，要用一条真实提交来验证。

已启用的表单需要改字段吗？ 不需要改原有字段。验证凭据由组件产出并随请求提交，字段定义可以保持不变，模板侧只需按说明引入脚本。

为什么垃圾提交还是进来了？ 先检查后台两项凭据是否齐全，再确认这条表单接口是否走到校验环节；若提交本身通过了人机验证，那么要处理的就是内容层，靠敏感词过滤与关键词替换收敛。

人机验证能替代人工审核吗？ 不能。它只判断请求是否来自自动化脚本，不判断内容是否合规，仍需内容审核决定发布与否。

多站点情况下要逐个站点配置吗？ 验证设置是按站点生效的，多站点要逐个确认凭据与开关，不要假设主站配置会自动带到其它站点。