长时间处理需要进度指示，避免用户重复提交
别名: 提交中进度 · processing spinner · 防等待中重提
概念解释
提交之后若要等秒级以上的处理（上传、风控、生成编号），空白等待会被读成死掉。进度指示让人看见这次提交仍在进行：不确定等待的活动态，或能估计剩余的分段。它的直接作用是挡住「再点一次」的判断，而不是告诉人已经成功。按钮禁用是入口层的锁；这里是成功/失败揭晓之前的过程层。过程结束之后的确认句、下一步、部分失败，是另外三步。
机制
超过约一秒没有新证据，人把「进行中」改判为「没开始」。空白越长，重提的冲动越强，尤其在上传这种看不出字节在走的场景。进度把等待重新编码为工作。第二层是不确定与可估计要分开：不知道还要多久时，活动态加「正在处理提交，请不要关闭」就够；能分段时（上传 → 校验 → 编号）用阶段名，人才能判断是不是卡死。假进度条走到 99% 停住，会把耐心耗在最后一格，然后触发刷新——刷新在处理未完成时可能变成第二次提交。指示必须和真实阶段绑定，不能用匀速动画假装知道终点。
怎么研究
把处理时间做成 2 秒、8 秒、30 秒，比较无指示、转圈、假进度条、真实阶段名。看重提、刷新、关闭。
自变量：处理时长、指示类型（无 / 活动态 / 假条 / 阶段名）、入口是否同时禁用。 因变量：等待中的重提或刷新、关闭页面比率、把假条卡死当成失败的次数。
实验室里被试被要求等，重提会被压住。指令改成「你觉得没反应就按你平时会做的做」。不要用按钮是否禁用代替进度——禁用了仍会刷新页面。
边界
低于一秒的提交，进度会闪一下变成噪声，用按钮等待态就够。处理变成分钟级（人工审核）应改成「已受理，结果稍后通知」，不要让人盯着一条走不完的条。状态未知的支付不能用进度假装还在扣款，应改查询。离线时进度应改成「将在联网后发送」，继续转圈是撒谎。屏幕阅读器需要活区域宣布阶段变化，否则进度只对视力用户存在。
怎么落地
- 预计超过一秒的提交，在结果出来前显示活动态或真实阶段，并写「请不要关闭 / 刷新」。
- 有真实阶段就用阶段名；没有就用不确定等待，不要做匀速到 99% 的假条。
- 过程中保持入口禁用；刷新或返回要提示「仍在处理」，而不是再发一次。
- 验证：把接口延迟到 8 秒，看有没有人刷新或再点。做一条停在 99% 的假进度，统计有多少人刷新。开阅读器，确认阶段变化被宣布。支付未知态不得显示「正在扣款」的假进度。