表单提交防垃圾处理实战：高效拦截恶意提交

52JinY 助手

做表单的人，十有八九都被垃圾提交折磨过。最开始我也想得很简单，无非就是加个验证码，结果上线没几天，后台照样一堆机器灌进来的内容，邮箱提醒响个不停。后来慢慢踩坑才发现，表单防垃圾这件事根本不是“加一个功能”就结束，而是要把体验和拦截一起考虑。

我现在比较反感那种一上来就把用户当贼防的做法。很多网站动不动就是图片验证码、点选验证码，手机上尤其难受，正常用户填个联系方式都要试两三次，最后真正被劝退的是人，不是机器人。垃圾提交确实要拦，但如果代价是让真实用户也不想提交，那这个防护其实已经失败了一半。

比较实用的一条思路，是把“显眼的强拦截”改成“安静的多层过滤”。比如最基础的隐藏字段，也就是常说的 honeypot，对不少低质量脚本依然有效；再比如限制提交频率，同一 IP、同一设备指纹、同一时间段内连续提交过多，就先进入观察或直接限流；还有前后端都做字段校验，像超长内容、异常链接数量、可疑关键词、秒速提交这类特征，其实很容易筛出一批明显不正常的请求。单独看每条规则都不算神奇，但叠起来效果通常比单纯堆验证码更稳。

我自己比较看重“时间维度”的判断。真人填写表单，通常要几秒到几十秒，机器人往往是打开页面立刻提交，或者固定节

奏地批量发送。所以我一般会给表单埋一个生成时间戳，提交时判断停留时长，过快的直接打低分，不一定当场拒绝，也可以转入二次校验。这个办法的好处是对正常用户几乎无感，但对很多脚本特别有效。再配合一次性 token、来源页校验、CSRF 防护，至少能挡住一批最省事的攻击。

还有一点很容易被忽略，就是不要迷信单一指标。IP 可能是共享出口，关键词也可能误伤正常咨询，地区限制更是经常把真实用户挡在门外。比起“命中一条就封”，更合理的是做风险评分：命中隐藏字段加几分，提交过快加几分，短时间重复内容再加几分，超过阈值再拦截或者进审核。这样策略会柔和很多，维护起来也

更有余地。尤其是业务量一大之后，你会发现防垃圾不是一次性工程，而是需要不断根据日志去调规则，今天拦得住的脚本，下周可能就换了套路。

再往后做，日志和数据分析其实比“拍脑袋加规则”重要得多。哪些表单入口最容易被打，哪些字段最常被利用，垃圾提交集中在什么时间段，拦截后误伤率高不高，这些都应该有记录。很多团队前期只顾着加拦截，出了问题却不知道是哪条规则在生效，最后只能一刀切地把验证码强度继续拉高，用户体验也跟着越来越差。我的经验是，能记录就尽量记录，哪怕先做个很粗的后台统计，后面调策略时都会轻松很多。

如果业务允许，分级处理也很有用。比如留言板、活动报名、试用申请，这几类表单的价值和风险完全不一样，就没必要用同一套强度。低风险表单可以偏重体验，高风险表单再叠加邮箱验证、短信验证，或者把高风险内容先放进审核队列。这样做比全站统一上最严策略更实际，也更省资源。

还有个很现实的问题：别把所有希望都压在前端。前端的校验、埋点、隐藏字段都

可能被绕过，真正决定是否入库、是否发通知、是否触发后续流程的，必须在服务端再判断一遍。很多垃圾提交之所以烦人，不是因为它进来了，而是因为它顺带把邮件、短信、工单这些后续动作全触发了，结果成本一下就上去了。所以我的习惯是把“接收请求”和“确认有效”拆开，先收、先判分、再决定要不要落库和通知，这样整个链路会安全很多。

说到底，表单防垃圾没有银弹。验证码不是不能用，但它更适合当最后一道门，而不是第一反应。真正好用的方案，通常都不花哨，就是几种低打扰手段叠加起来，再配合持续观察和调整。用户觉得提交过程顺滑，后台又能把大部分脏数据挡在外面，这才算是做对了。很多时候，防垃圾拼的不是谁规则更狠，而是谁更理解自己的业务和正常用户长什么样。