咨询表单重复提交怎么办？按钮防重、服务端幂等与线索去重方法

客户在企业网站点一次“提交咨询”，后台却出现两三条相同线索，销售重复回访，客户也会怀疑系统是否正常。重复记录可能来自用户连点、网络慢时再次提交、页面脚本绑定了两次事件，或请求已成功入库但前台没收到响应而自动重试。只把按钮改成灰色不能解决所有情况；需要让前端反馈、服务端写入与后台判重配合。

前端让用户知道“正在处理”

表单通过校验后，按钮进入提交中状态，阻止同一界面连续触发；成功后显示明确结果，失败时说明是否可以重试。不要只在按钮的点击事件里拦截：用户还可能按回车触发表单提交，脚本也可能调用提交接口。MDN说明submit事件由点击按钮、隐式提交或requestSubmit()触发，开发时应核对实际监听位置。客户的输入内容在网络失败后应保留，避免重新填写。

服务端决定记录是否只创建一次

浏览器可能断线、刷新或重发请求，因此后端不能把“前端禁用了按钮”当作唯一保障。常用做法是在一次提交意图上生成唯一标识，服务端在写入时检查并保存该标识；同一标识重复到达时返回已有结果，不再创建新线索。若是支付、预约等更严格的业务，还要考虑并发请求、不同内容复用标识以及有效期。IETF正在讨论的Idempotency-Key草案给出了这类机制的描述，但具体系统应按自己的接口和数据库约束设计。

后台“相似客户”不等于“同一次请求”

同一个手机号隔几天再次咨询，可能是新的真实需求，不能直接丢弃。后台可以对手机号、项目、时间窗口标记“疑似重复”，交给客服确认；用于保证同一次请求只入库一次的提交标识则应由程序处理。统计时也要分清按钮点击、请求成功和有效咨询线索。如果咨询根本未进入后台，先按表单收不到消息的排查清单检查发送链路。

1. 测试快速连点、按回车、刷新页面和网络超时后重试。
2. 观察前台是否给出“处理中/已提交/失败”三种清楚状态。
3. 确认同一提交标识在服务端只产生一条记录。
4. 检查后台是否保留必要的请求时间与处理状态，便于客服核实。

重复提交处理得当，既能减少无效回访，也能避免把真实客户第二次提出的新需求误删。表单字段本身仍应按咨询表单设计指南保持必要、清楚和安全。

资料依据：MDN表单submit事件说明；IETF幂等请求头草案。