失败后必须恢复可提交状态
别名: 提交恢复 · unlock submit · stuck disabled button
概念解释
入口为了挡住连点被关掉之后，这次请求若失败、超时或被取消，同一意图还需要再送一次。恢复可提交指失败一旦确定，主按钮和回车重新可激活，文案从「提交中」回到提交动词，焦点回到可操作的入口或首个错误。成功的请求不应恢复入口去鼓励再送一笔；失败的请求若不恢复，人被锁在一张废表上。这条谈的是失败路径如何开门，不是第一次点击如何关门。
机制
禁用是针对「这一次尝试」的锁，不是针对「这个表单余生」的锁。失败把尝试结束掉：网络错误、4xx 校验、5xx、用户取消。锁若还在，界面声称「正在提交」，实际已经没有进行中的请求，人的模型与系统状态分裂。第二层是失败类型决定恢复后的落点：传输失败应把入口还在原处并解释「没送出去，可以再试」；业务校验失败应恢复入口但把人送到错误项，避免恢复成再点一次就再撞墙；成功则保持关闭并进入结果。把所有失败都做成「按钮继续转圈」是最糟的中间态：既不能改，也不能走。超时特别容易留下这把锁，因为回调没回来，客户端以为还在飞。
怎么研究
分别制造网络断开、422 校验失败、500、用户点取消，观察入口何时恢复、文案是否回到动词、焦点在哪。
自变量：失败类型、是否有超时上限、取消是否中止请求。 因变量：失败确定后入口是否可再点、从失败到可再提交的延迟、卡在「提交中」无法离开的次数、恢复后第一次再提交是否带着未修正的同一错误。
实验室用 mock 立刻返回，测不到超时悬挂。要加一个永不返回的请求。不要把「失败后自动重试」算成恢复——自动重试期间入口应保持关，恢复发生在重试放弃之后。
边界
支付、下单等「状态未知」不是确定失败：入口不能贸然恢复去鼓励再下一单，应改为查询而不是再提交。部分成功（附件上传了、主记录没建）恢复入口前要说明哪些不要再送。被踢下线导致的失败，恢复提交只会再失败，应改为登录路径。离线时可以恢复入口让人改内容，但真正的发送应进队列并显示「将在联网后发送」，避免装成又一次即时提交。
怎么落地
- 为提交设超时；超时、网络错误、明确的失败响应和用户取消都必须把入口恢复为可激活，并去掉进行中文案。
- 校验失败：恢复入口，同时把人带到错误，不要只亮按钮让人再撞一次。
- 成功或「已接受正在处理」：保持入口关闭，进入结果或进度，不要为了对称而重新点亮。
- 验证：断开网络点提交，确认若干秒后按钮回到「提交」且可点。返回 422 时按钮可点且焦点在首错。做一个永不返回的请求，确认超时后不会永远「提交中」。支付类在状态未知时按钮不得自行恢复成「再付一次」。