蜜罐字段和验证码各自挡哪类垃圾提交，能不能只留一个

蜜罐字段和验证码各自挡哪一类垃圾提交，能不能只留一个？两者作用面不同：蜜罐靠隐藏字段识别不解析样式的脚本，对真实用户完全无感；验证码靠评分或挑战识别人机，代价是会拒绝掉一部分真实访客。只留一种是否成立，取决于站点垃圾的构成，而不是哪种手段更”强”。

两种手段的作用面不同

蜜罐的判定依据是行为差异。真实用户由浏览器渲染页面后填写，看不见的字段不会去动；而按字段名直接构造请求的脚本会把所有可写字段都填上。服务端看到蜜罐字段非空即可判定为机器提交。它对先渲染再提交的脚本无效，相关实测口径是对基础脚本类提交约有四成拦截率。

验证码的判定依据是人机区分成本。带评分的一类不给用户可见挑战，而是按请求特征给出机器人可能性分数，分数低时拦截或加验证。它的风险正来自这一层：判定依赖统计特征，特征接近真实用户的正常访问就会被误判，这也是它可能拒绝真实访客的原因。

另一条边界是代打服务。按次付费让真人完成验证的服务客观存在，说明验证码抬高的是自动化成本，而不是把所有提交都挡在门外。

误伤来自哪一层

误伤不发生在蜜罐上，而集中在三层。

第一层是评分阈值。阈值偏严时，网络环境受限、使用旧设备或代理出口的访客分数偏低，即便没有恶意也会被拒。第二层是可达性。部分访客所在网络取不到验证服务所需的资源，挑战无法完成，表现为提交一直失败。第三层是流程摩擦。验证环节拉长填表时间，用户放弃的比例上升，这部分损失不会出现在拦截日志里，最容易被忽略。

蜜罐的失败面不同：它不会拒绝真实用户，只做静默判定，风险在于漏放而不是误伤。两者恰好互补，这也是同时配置的原因。

下表按垃圾构成列出该留哪一种。

只留一个成立的条件

只留蜜罐成立的情形有三种：垃圾几乎全是脚本批量提交；表单承担的是转化路径，任何摩擦都直接损失客户；站点没有能力持续观察阈值变化，宁可不拦也不要拦错。

只留验证码成立的情形更窄，一般出现在垃圾已经明显绕过蜜罐，且业务允许一定比例用户完不成提交的场合，比如资格申请、限量报名一类。

其余情形下”只留一个”往往不成立，原因不是两种手段都要用，而是缺少中间那两层：来源与频率限制，以及内容层面的过滤。多数情况下真正起作用的是四层顺序配置，而不是某一层单独加到最严。

两种都要时的搭配写法

搭配的关键是让两层各判各的，不要串成一条硬链。

蜜罐做静默判定，命中后不提示用户，直接丢弃并留记录；评分型验证放在提交前，按分数决定放行、追加挑战还是拒绝；两者结果都写入状态流，可疑但不确定的提交进入待确认而不是直接删除。

留痕这一步很重要。AnQiCMS 的内容状态本身分为正式、草稿、待发布与回收站，误删只是移入回收站而非物理删除，表单与留言的处理可以沿用同样思路：被拦下的提交先保留可恢复的状态，等确认后再清理。这样误伤可以追溯，拦截率也能统计出来。

配置完成后看两个指标：垃圾提交占比是否下降，真实提交总量是否同步下降。后者若跟着掉，说明误伤已经发生，要放宽阈值而不是继续加层。

常见问题

蜜罐会不会被脚本直接跳过？ 会，前提是脚本先渲染页面并解析样式。对这类提交要靠评分验证与频率限制补上。

验证码分数低一定能拦准吗？ 不能。评分是统计判断，特征接近真实用户就会被拒，阈值要按自己站点的误伤情况调，不能照搬默认值。

被拦下的提交留多久？ 按能完成一次复核的长度留，通常保留到确认垃圾或确认误伤为止，之后按状态流清理，不要静默丢弃导致无法追溯。