手机上填完一张业务申请，点了提交，页面转了一会儿，提示“请求超时”。再点一次，终于看见成功；后台却多出两张申请单。对常州企业的小程序、报修登记或内部申请系统来说，这类重复不能只靠提醒员工“别多点”解决。
先看一种可能的过程：第一次请求已经到达系统，申请也已经保存，只是成功结果返回手机时连接中断。页面没有收到答复，于是显示超时。使用者以为没有提交，系统却已经办完；第二次点击若又创建一张记录，一次申请就变成了两笔待处理工作。
因此，超时说明这次等待没有拿到结果，并不能单凭它判断申请一定没保存。反过来，也不能一律显示成功，因为请求可能确实没有到达。页面需要区分“尚在确认结果”和“已经确认未成功”，并提供查询本次申请的办法，而不是让人反复试到成功为止。
拦住双击，与认出同一次申请，是两件事
点击后把按钮暂时禁用，有助于减少连点，但它只控制眼前这个页面。刷新、重新进入、网络恢复后的重发，都可能绕过这层限制。若结果尚未查明就重新开放一个会创建记录的按钮，重复风险仍在。
较可靠的设计，是给这一次提交安排一个操作标记。第一次发送和因超时发起的重试，都带着同一个标记；系统认出处理过这次操作时，返回原来的单号或结果，不再创建第二张申请。这个标记应与本次输入一起保留，不能每点一次重试就重新生成，也不能随意填入客户姓名、电话等个人信息。
只按“姓名、事项和数量相同”去重，反而会拦住正常工作。假设员工先申请一批物料，随后又确实需要同样一批，内容可以完全一样，但这是两笔业务，应通过明确的“重新申请”生成新标记。超时后的“继续查询或重试”，则应沿用原来的标记。按钮名称和处理方式要让人分清这两种意图。
还有一个边界：同一标记下，使用者把数量改了怎么办？系统不能悄悄把旧结果当成新数量的成功回执。应说明本次内容与原提交不同，查清原申请后，再按业务规则修改或另建。记录创建和操作标记的占用也要一致完成；只在保存前查一下“有没有提交过”，两次请求同时到达时仍可能一起通过。
验收时，让结果晚回来一次
讨论小程序或业务系统开发时，可以把下面三种操作交给开发方，在不含真实业务数据的测试环境中演示。它们要回答不同问题，不能只看按钮最后变成了什么颜色。
- 快速点两次同一提交：查看是否只生成一张有效申请，两个请求是否指向同一结果。仅把按钮做灰，还不能证明系统能够识别重复。
- 让系统保存后延迟返回结果，再从页面重试：这是检查“已处理、未收到答复”的关键情形。只在提交前断网，测到的可能只是请求没发出去，不能代替这一项。
- 完成后明确发起第二笔相同内容的申请：按实际规则应允许另建时，要产生新单号。防重复不能把合法的后续申请一起挡住。
如果第一次仍在处理中，再次请求可以显示处理中并继续查询，不必为了立刻给出答复而重复创建。若申请已保存、通知却发送失败，应单独查看通知状态；补发通知不应重新生成申请。操作标记保存多久、跨设备如何查询，也要结合业务约定，不能照搬一个固定时长。
提交后的体验，应让使用者知道这次申请在哪里、现在是什么状态，以及下一步能做什么。结果不明时能找回原记录，确实要再办一笔时能另建，系统才能同时做到少出重复单、不漏掉真实需求。
返回列表