E1.09.3cancelable loading button设计研究
长时间加载需提供取消
别名: 加载可取消 · 提交取消 · abort in-flight
概念解释
锁定防止重复发送，但不该把人关进一次无法脱身的等待。当加载明显长于一次短反馈——上传、支付确认、远程渲染——界面需要一条取消（cancel / abort）路径：停下请求、解开按钮、回到可编辑状态。长时间加载而无取消，人只能杀进程、后退或反复点已经锁死的键。
机制
等待的可忍受长度取决于能否离开。已知自己能取消时，人会把注意留在任务上；不能取消时，不确定感把等待放大，催生杀应用、重复打开、用另一台设备再提交——这些才是真正的重复。取消不是撤销已经成功的事务，而是中止尚未完成的那一次。它需要请求可被 abort（客户端取消 fetch、服务端丢弃未完成任务），否则按钮上的「取消」只是本地解开，服务器仍可能稍后写成功，造成「我取消了却仍下单」。长时间还涉及进度是否可知：不可知的转圈更需要取消，因为人无法判断该再等还是已经死了。
怎么研究
把提交延迟设为 8–20 秒，对比有取消 / 无取消。允许杀进程和后退。记录人们何时放弃、放弃走哪条路、取消后服务器是否仍完成写操作。
自变量：延迟长度、有无取消、有无确定进度、取消是否真正 abort 服务端。 因变量：放弃率、杀进程率、取消后的幽灵成功、再次进入任务的时间。
实验室里被试知道这是实验，杀进程率偏低。要在自己的设备、自己的账号上才容易看到「我怕扣两次款所以杀掉」的真实动机。
边界
200 ms 内结束的请求给取消会闪一下，得不偿失。一旦服务器已提交事务（钱已扣），取消应变成「撤销 / 退款」而不是 abort，否则文案在说谎。离线排队的发送，取消的是队列项，要写清楚还没发出去。无障碍用户需要取消本身可键盘到达，不能只出现在转圈装饰里。
怎么落地
- 超过几秒仍无结果的操作，在按钮旁或把按钮本身改成可点的「取消」，并真正 abort 请求。
- 取消后恢复可编辑内容和解锁，不要清空表单。
- 若事务可能已在服务端完成，取消成功时要核对并如实说「未发送」或「已发送，去撤销」。
- 验证：在 10 秒假延迟里点取消，网络面板应看到请求中断，且服务端无对应成功写。取消后立即再提交应只产生一笔新请求。