网站接了 reCAPTCHA 却没有拦截效果，排查顺序应该是”先静后动”：先查配置层的密钥与域名绑定，再查前端层组件是否真的参与提交，最后查服务端的校验逻辑与网络出口。三层各自对应一类典型故障，盲目重装组件往往解决不了问题，因为最常见的失配点根本不在组件本身。

一层：密钥与域名绑定对不对

reCAPTCHA 的站点密钥与保密密钥是成对的，且注册时绑定了允许域名。这一层最容易出三类问题：测试密钥没换成正式密钥；域名绑定和实际访问域名不一致，比如注册的是裸域、访问走了 www 子域，或者上线前用预发布域名注册、正式域名没有加进允许列表；还有把前端密钥与服务端密钥填反位置的。

核对方法是把”注册域名、前台加载域、表单所在域”三个值放在一起比对，任何一处不一致，验证请求都会被服务商拒绝，而很多表单实现遇到拒绝时默认放行，表面看就是”配了但没生效”。

二层：组件挂没挂到提交流程

验证码在页面上渲染出来，不等于提交动作真的带上了验证令牌。常见断点有三个：表单是动态渲染或弹层里的，组件初始化时机早于表单出现，令牌从未生成；前端自行拦截了提交事件走异步请求，请求体里没有携带响应令牌；页面接了多个表单，只在主留言区配置了验证，注册、找回密码等其他入口仍是裸提交。

验证方式是观察一次真实提交：网络面板里请求参数应带上验证码响应字段，提交被拒时表单应给出可感知的失败反馈。如果请求根本没经过校验就直接入库，说明前台渲染和服务端校验之间没有闭环，机器人只需要绕过你的页面直接提交接口，页面上的验证框就形同虚设。

真正的拦截发生在服务端：收到提交后，服务器要带着令牌去请求验证接口，根据返回结果决定放行与否。这一层的故障多在网络：服务器所在机房到验证接口的出口不通或被防火墙拦掉，请求超时后代码走了”失败即放行”的分支；反向代理配置改动后丢掉了提交携带的字段；还有校验结果没有落日志，导致实际拦截率无从确认。

上线前建议在后台保留一个可查询的校验记录入口，哪怕只是简单的是否通过标记，也能在垃圾提交突然增多时快速定位是哪层断了。AnQiCMS 的表单可以直接接入 reCAPTCHA 验证码防机器人，属于内置的内容安全能力，配合系统对 SQL 注入和 XSS 攻击的防御，前台表单不必自行实现校验逻辑。

要清楚验证码的边界：它判断的是”这次提交像不像人”，不判断”这条内容本身好不好”。真人代提交、脚本攻破弱验证后涌入的营销内容、垃圾链接，都是通过了验证混进来的。所以表单防线要有第二段：敏感词过滤与关键词替换负责内容层清洗，内容审核负责流程层把关，再叠加评论反垃圾对提交频率与行为模式的控制。

换句话说，reCAPTCHA 挡量，敏感词与审核挡质，两层都闭环才是完整的表单防护。排查”没生效”时也一样：先确认量这一层断在哪，再检查质那一层是否本来就缺位。

Q：页面能显示验证码框，是不是说明配置没问题？ A：不是。显示只证明前端密钥可用，域名绑定与服务端校验仍可能失败，必须做一次真实提交并检查服务端校验结果。

Q：服务端校验失败时应该放行还是拦截？ A：建议拦截并提示重试，宁可误伤一次提交，也不要”失败即放行”；同时给校验失败留日志，方便区分配置错误与网络抖动。

Q：接了验证码还需要敏感词过滤吗？ A：需要。验证码管提交来源，敏感词过滤与内容审核管内容质量，两者覆盖的垃圾类型不同，互为兜底。