摘要：官网同一询盘重复进入CRM时，不能只按邮箱删除。本文说明怎样区分双击、接口重试和邮件导入，并建立请求号、合并规则及复核记录。
官网同一条询盘在CRM里出现两三次，不能直接按邮箱合并。应先判断是访客双击提交、浏览器或网关重试、表单同时发邮件与写接口，还是销售再次转发导入。修复时为每次提交生成唯一请求号，保存原始来源与附件指纹，再按明确规则合并，避免误删同一客户的不同项目。
用请求链路判断重复记录从哪里产生
先取一组确认重复的记录，不要只看姓名和邮箱。对比创建时间、表单页面URL、来源渠道、IP、浏览器标识、附件文件名、正文哈希、CRM记录ID和邮件Message-ID。两条记录相差不到一秒、字段完全一致，常见于按钮连续触发；间隔数秒且请求号相同，可能是网络层重试；一条来源为API、另一条来源为邮箱解析，则要检查系统是否把同一次提交走了两条入库路径。
前端双击要在真实页面复现。打开浏览器网络面板，填写测试数据，快速点击两次提交按钮，观察是否发出两个POST请求。按钮变灰只是一层交互保护，不能代替服务端去重，因为访客刷新、弱网重发或脚本调用仍可能重复提交。服务端应接收一个由前端生成或由入口分配的submission_id，并在数据库中设置唯一约束；相同编号再次到达时返回已有结果，不新增记录。
网关和接口重试要看状态码与超时。表单已写入CRM，但接口响应在途中超时，调用方可能把它当作失败再次发送。日志字段至少包含request_id、received_at、upstream_status、duration_ms、retry_count和crm_record_id。若第一次实际创建成功却返回502或连接中断，第二次请求需要查询幂等键对应结果，而不是再次执行创建动作。不能通过延长超时时间掩盖缺少幂等处理。
邮件链路也会制造重复。网站提交后既调用CRM接口，又发送到销售邮箱；邮箱插件随后把同一封信解析进CRM，就会得到两条来源不同的记录。核对邮件头、收件地址、转发规则和插件导入时间。解决办法可以是停用其中一条自动导入，也可以让邮件携带submission_id，导入前查询该编号。销售人工转发的客户补充邮件则不能被错误合并到原询盘。
建立不会误伤真实商机的合并规则
强去重键优先使用submission_id、表单事务号或可信邮件Message-ID。附件可计算SHA-256作为辅助证据，但同一张图纸可能被客户用于多个询价，不能单独作为删除依据。邮箱、电话和公司名适合找候选重复，不适合作为唯一键；同一采购人员一天内询问两个型号，属于两条真实需求。
候选合并规则应同时考虑时间窗口和业务字段。例如“同一submission_id永久视为同一次提交”；没有编号时，可把“同一邮箱、同一页面、正文哈希一致、附件指纹一致且10分钟内创建”标记为高置信重复。字段示例用于说明方法，窗口应根据站点流量和销售流程调整。系统先标记，不立即物理删除，保留duplicate_of、判定原因、处理人和处理时间。
合并时确定主记录。通常保留最早成功入库且来源字段完整的一条，把后续记录的技术日志、附件状态和跟进动作追加到主记录。若重复记录已经分别分配给不同销售，先暂停自动提醒，再由负责人决定归属。任何报价、备注或客户回复都不能在合并中丢失；无法自动判断时进入人工复核队列。
修复上线后准备四组测试：快速双击、提交后刷新、模拟接口超时重试、邮件自动转入。每组记录预期请求数、CRM新增数、页面提示和日志结果。正常情况应是请求可能重复到达，但CRM只保留一个主商机，并能追溯所有尝试。还要验证第二个不同型号、不同正文或不同附件的询盘不会被合并。
销售端需要看到“疑似重复”而不是突然少一条记录。列表可显示主记录链接、重复来源和合并原因，允许授权人员撤销误判。每月统计重复来源分布：前端双击、接口重试、邮件导入、人工创建各占多少。若某一来源持续上升，应修对应链路，不能把越来越宽的合并条件当成长期解决办法。
