评论垃圾突然变多，验证码、内容审核和频率控制各管哪一段

垃圾评论和表单灌水变多时，三类防护各自挡的是不同环节的问题。验证码管的是提交动作是不是机器发起的；敏感词过滤与内容审核管的是提交上来的文字能不能对外露出；频率控制管的是同一个来源在短时间内提交了多少次。三段各管一段，谁也补不了谁的缺口，顺序配错就会出现「开关都开了，垃圾还是照样进来」。

先分辨是灌水还是攻击

同样是评论区变脏，成因不一样，处置手段也不同。批量广告链接属于灌水，内容是正常文字，靠语义就能认出来；带脚本的注入尝试属于攻击，内容短、格式怪，但危险在渲染环节；真人手动发帖则两类都不是，只能靠审核。动手之前先抽几十条看一遍：链接是不是重复指向同一批地址，正文是不是模板化，提交时间是不是集中在深夜。这一步决定后面该先开哪一段，而不是先开哪一段都行。

验证码挡的是自动提交

表单侧接入 reCAPTCHA 之后，拦截发生在提交之前：脚本没有通过人机校验，请求根本进不了业务逻辑。它的价值在于把批量灌水的成本抬回去，对「一小时发两千条」这类行为效果最直接。

但验证码不理解内容。机器只要通过校验，后面写什么都放行；反过来，真人用户如果被反复要求校验，体验会直接下降。所以验证码适合配置在留言、评论、注册这类写入口上，而不是全站所有请求。它挡的是提交动作，不是提交内容，这一段不能指望敏感词过滤来替代。

过滤与审核挡的是内容

敏感词过滤解决的是命中规则的内容怎么处理，通常配成拦截或者替换，关键词替换可以把不适合对外的词换成占位或温和表述。内容审核解决的是这条记录要不要公开露出——通过、驳回，还是先进待处理状态等人工确认。

这一段管的是语义与规则，不看提交来自人还是机器。同一条广告文案，人工提交和脚本提交在它眼里没有区别。因此它和验证码是两条独立链路：一个管入口，一个管内容。只开一条就会出现「机器挡住了，人发的广告还在」或者反过来。

频率控制管的是提交节奏

同一来源短时间内的提交次数，一般不在评论功能内部处理，而是在入口层、反向代理或者网关上配置。它挡的是「量」，不管内容合不合规：一条正常的帖子和一条广告，在速率限制眼里是同一个请求。

速率阈值不要凭感觉设。先看正常用户在最活跃时段实际发了多少，再留出余量，否则活动期会误伤真实用户。它和验证码可以叠加：验证码负责单条请求的机器识别，速率限制负责累计次数。

状态控制决定有没有对外露出

三段之外还有第四段常被忽略：内容进来以后处于什么状态。以 AnQiCMS 的文档状态划分来看，正式文档对外可见，草稿可以带预览参数查看，待发布内容按设定时间才放出来，删除则是移入回收站而不是物理删除。评论与留言的待审核逻辑类似——不外露就等于没有对外风险。

这里有一处容易漏：待审核内容前台不展示，但后台列表仍然会把它渲染出来。审核人员打开列表时，原始内容会被浏览器解析，所以输出转义不能因为「这条还没发布」就省掉。防采集干扰码、敏感词过滤这类机制处理的是对外展示，管不到后台列表；跨站脚本风险要靠转义来挡，而 SQL 注入要靠参数化查询，两者都不是关键词表能解决的。

三段各自挡不住什么

调整之后要观察，不要当场下结论

反垃圾规则的效果需要时间才能看清。收紧验证码或者过滤词表之后，正常提交的转化率会立刻变化，但广告变体的出现通常滞后几天。改完先观察一周再看数据，比当场判断更可靠。

一次只改一段，改完记下改的是哪一段，否则效果变好或者误伤时无法归因。词表命中量大的词条要抽样人工看，批量替换规则一旦写错，全站历史内容都会被牵连。

常见问题

只开验证码够不够？不够。验证码只挡机器提交，人工批量灌水和带脚本的内容都能通过它进来。

敏感词过滤和审核队列能互相替代吗？不能。过滤是规则命中即处置，审核是人工确认后才对外，规则覆盖不到的语义变体只能靠审核。

误伤了真实用户怎么办？先回退最近一次改动的那一段，再放宽对应阈值，不要三段同时调低。

为什么待审核内容还要管转义？前台不展示不等于不存在，后台列表会直接渲染原始文本，攻击者可以故意提交等待被查看。

一个判断口径

三段防护按提交前、提交时、提交后依次排开：验证码管入口，过滤与审核管内容，频率控制管节奏，状态控制管露出范围。判断自己配漏了哪一段，只需要问一句——这批垃圾是在哪一步本应被拦住的。