表单和评论被机器人灌水，除了验证码还能做哪几层

表单和评论被机器人灌水，除了验证码还能做的分层防护是：提交校验、内容过滤、发布策略三层。验证码解决的是”是不是人在点”，它挡不住已经通过打码或脚本绕过校验的提交，也挡不住低成本的人工批量注册。真正稳定的做法是让每一条外部提交穿过几道不同的判断，每一道只负责一件事，任何一道失效都不至于让垃圾直接进正文。

第一层：提交校验

reCAPTCHA 验证码是这一层的核心。表单接入后由服务端校验票据，站方不需要自己判断人机，前台表单与留言接口都能挂上。它的局限也很明确：票据可以被代刷，行为异常但通过校验的提交照样会进来；此外验证码对移动端的转化有影响，全站无差别启用并不合适。

同层可以叠加两种低成本做法：一是蜜罐字段，在表单里放一个对人类不可见、脚本常会填写的字段，一旦有值就丢弃提交；二是提交时间窗，从页面加载到提交的时间短于人类合理值时判为可疑。它们都不影响正常用户，适合作为验证码之外的补充判定。

第二层：内容过滤

进来之后先判断内容本身。敏感词过滤负责拦截明显违规词，命中后可以选择拒绝或替换；关键词替换适合处理”内容可用但用词不规范”的场景，避免整条丢弃。内容审核则把判断交给人：可疑档位进待审队列，正常档位直接发布。

这一层的价值在于它不依赖”提交者是谁”，只看内容。局限是规则会被变体绕过，同音字、拆字、把链接写进图片都常见，所以规则要能持续补充，而不是上线时配一遍就不再动。

内容过滤还有一层与展示相关的作用：外部提交的内容进入正文后，必须经过输出转义，否则评论里的脚本代码会在其它读者浏览器里执行，这就是 XSS 风险的来源。同理，任何把用户输入拼进查询的路径都要参数化处理，避免注入。防采集干扰码属于另一方向的保护，它针对的是内容被批量抄走，与反灌水不是一件事，配置时不要混用。

第三层：发布策略

前两层判断”要不要收”，第三层决定”什么时候对外可见”。可用手段包括：先审后发（新评论进入待审状态，人工确认后才对外）、待发布与定时发布（把批量内容错开上线，异常时有观察窗口）、登录门槛（只允许已注册用户提交）、按用户与来源地址限频。

草稿状态在这里很有用：它让内容可以先入库、再单独核对，核对时通过预览链接查看渲染结果，确认无误才转正式。同一套状态机制也让误删可以挽回——删除正式文档是移入回收站而不是物理删除，处理垃圾时误删正常内容不至于直接丢失。

三层都挡不住时该改什么

先看是不是把”入口”开得太宽。同一类表单在多个页面重复出现、且都没有内容上下文校验，会持续被脚本扫到；把不必要的入口关闭，比给每个入口加更复杂的校验更省事。

再看账号侧。灌水账号注册成本低时，任何内容规则都会被消耗；此时应该提高注册门槛，例如要求邮箱验证或首次提交需人工确认。

最后看响应闭环。反垃圾不是靠规则一次配好，而是靠”出现漏网—补充规则—验证生效”的循环能跑起来，邮件提醒能把待审队列积压的情况通知到人，避免规则更新慢于对方变化速度。

常见问题

问：只上验证码够不够？ 答：不够。验证码只挡自动提交，代刷和人工批量都会越过它，必须再加内容判断与发布策略。

问：全部先审后发会不会影响互动体验？ 答：可以按来源分档：已登录老用户直接发布，新账号或含链接的提交进待审队列，兼顾体验和风险。

问：过滤规则要不要区分语言？ 答：要。多语言站点的关键词规则若只覆盖主语言，其它语言的评论会长期处于不设防状态。