网站优化 官网表单收到无效询盘怎么办：四个可落地的防护动作

企业官网的留言表单，收到的往往不全是真实询盘。里面混着自动脚本的试探提交、同行或外包的推销留言、以及用户误触产生的空表单。如果不做处理，销售每天要花时间在无效信息里翻找真实线索，久而久之就没人认真看这个表单了。

这篇把我们自己在官网上做过的四件事整理出来。它们都不复杂，效果比想象中直接。

一、先分清无效提交的类型

不同来源要区别对待，用同一套规则处理反而容易误伤真实客户。

把这三类混在一起处理，通常会走向两个极端：要么拦得太松，垃圾照进；要么拦得太严，真实客户被挡在门外还不自知。

二、四个可以照着做的动作

1. 提交前先换一次性令牌

页面打开时向后端申请一个短期有效的令牌，提交时带上。后端校验通过后立刻作废，同一个令牌不能重复使用。

这一条挡掉的是"脚本直接构造请求重复提交"这类行为——对方拿不到令牌，或者令牌已经用过，请求就无效。令牌可以和一个短时效绑定，过期需重新获取。

2. 加一个正常人看不见的字段

表单里放一个通过样式隐藏的输入框。真实用户不会去填它，但很多自动化脚本会无脑填写所有字段——只要这个字段有值，就可以判定为机器提交。

注意要用样式隐藏而不是把字段设成不可用，否则部分脚本能识别出来并跳过。

3. 记录"打开到提交"的时间

页面加载时打一个时间戳，提交时一并带上。从打开到填完表单，通常需要几秒以上；如果只有不到一两秒，基本可以判断不是人工填写。

这里的处理方式建议是静默接受但不入库：接口返回正常结果，让对方以为提交成功，实际不进业务系统。理由在下一节说明。

4. 用词库标记而非直接拦截

维护一份和自己行业相关的词库，命中的提交打上标记、进入待复核队列，而不是直接拒绝。词库拦截容易误伤——同一个词在正常业务描述里也可能出现。

我们的做法是定期看命中记录，把明显属于推广的词留下来，把误伤的词移出去，让这份词库逐步贴近真实情况。

三、为什么"静默接受"比"报错拦截"更好

很多方案遇到疑似垃圾提交时，会返回一个明确的错误提示。这看起来更"正义"，但有两个问题：

• 给了对方反馈。明确的失败提示等于告诉脚本"这条规则被触发了"，对方调整一下就能绕过。
• 真实用户可能被误伤。一个手速很快、或者从浏览器自动填充提交的用户，会看到莫名其妙的错误，然后放弃。

相比之下，静默接受但不入库，对垃圾提交是"无声的拒绝"，对真实用户几乎没有影响。代价是你需要在日志里留下记录，否则无法判断是否误杀。

四、频率限制怎么做才不误伤

限流是另一个常用手段，但阈值定得太紧，被挡住的往往就是真实用户。

• 按来源限制。同一个来源在短时间内反复提交才拦。正常用户不会连续填两次表单。
• 按会话限制。同一浏览器已经提交过一次，再次提交走"已收到，请勿重复"的提示，而不是直接报错。
• 阈值参考。我们用的是每分钟二十次上下的量级，已经远高于任何人工填写频率，但足以拦住脚本的连续请求。

这里要特别注意共享出口的场景：部分企业网络、学校网络和手机运营商出口，会让大量用户表现为同一个来源地址。如果把这一项卡得很死，这类用户会集中受到影响。

所以频率限制更适合当作兜底——前面三条（一次性令牌、隐藏字段、时间窗）才是主要手段，限流用来拦住那些绕过前三条的漏网请求。

五、别漏了这三件小事

• 留下审计信息。每次提交记录来源 IP、时间、用户代理、命中了哪条规则。没有这些，你无法回答"到底拦掉了什么"。
• 定期看误杀率。抽样检查被拦下的提交，确认里面没有真实客户。这一步很多团队会省略，但它决定了防护规则能不能长期用下去。
• 别只防表单。同一个思路也可以用在接口上——需要登录或提交动作的接口，同样应该有频率限制和来源校验。

六、检查清单

七、小结

表单防护的目标不是把所有可疑请求都挡在门外，而是让销售打开后台时看到的信息值得看。判断标准很简单：连续抽查二十条询盘，如果里面只有一两条是垃圾，这套规则就是合适的；如果还有一半是推销，说明防护还没做到位。

如果你现在还没有做任何处理，建议从隐藏字段和提交时间窗这两条开始——改动量小，不需要额外的服务，通常当天就能看到效果。