按下后按钮立即 disabled 并报告 aria-busy；中途再点不发出第二次请求，完成后给出稳定结果可重试。防连点落在按钮本身。
产品与设计 · 交互状态与指针
按下态Active
按下瞬间的反馈状态，以及从激活到提交、完成或禁用的可操作性边界。
先按下、提交，再狂点测试防连点
一个真实的提交按钮：鼠标按下或键盘 Space/Enter 激活，观察按下 → 提交中 → 完成的物件变化；提交中再多按几下，看按钮上的「已阻止」涨没涨、请求有没有多发一次。取消勾选协议，再看业务禁用如何退出键盘顺序。
提交订单 · 防连点实验台
同一个提交按钮：按下有瞬时反馈，松开后进入「提交中」并禁用重复激活，完成后给出稳定结果。提交中再多按几下，看按钮上的「已阻止」涨没涨、订单请求有没有多发一次。
订单#204待提交
当前状态：默认
勾选协议后激活按钮，观察 按下 → 提交中 → 完成 的物件变化；提交中再多按几下，看按钮上的「已阻止」涨没涨、请求有没有多发一次。
从刚才的操作里提炼
你在实验台上看到的就是 active 与提交中、禁用的边界。
- active 是按下瞬时的激活反馈：按钮在你按下那一刻轻微下压，松开立即结束——它是瞬间，不是持续状态，和 hover（指针位置）、focus（键盘位置）不是一回事。
- 提交中 = 原生 disabled + aria-busy：松开后按钮进入提交中并真正禁用；实验台里提交中再点，按钮上的「已阻止」涨了，而「已发出请求」没有涨——重复激活被挡下。
- 完成后给出稳定结果，可重试：提交结束按钮变成「✓ 已提交 · 再次提交」，重新可激活；成功不是只靠颜色，物件上的文字和可操作性一起恢复。
- 业务禁用 ≠ 提交中：条件不满足（未勾选协议）时用原生 disabled 锁定，给出原因「需先勾选协议」，并退出 Tab 顺序——从不伪装成灰色的可点击。
- 状态不只用颜色：每个状态都伴随文字、可访问名称和可操作性的变化，并配 aria-busy / aria-live；读屏和低视力用户也能感知激活与结果。
什么时候关注 active
从用户信号判断，也要知道它与相邻状态的边界。
- 用：可操作元素在按下瞬间给瞬时反馈（轻微下压、变深），让用户确认激活已发生。
- 用：激活后进入异步提交时，用 disabled + aria-busy 防止重复副作用，完成后给可重试的稳定结果。
- 区分：hover 是指针位置、focus 是键盘位置、active 是激活瞬间——三者视觉可以相似，语义和触发时机不同。
- 不用：把「提交中」或「业务禁用」做成只变灰、仍可点击的按钮；灰色不是状态，disabled 才是。
怎么用：从按下到防连点的最短路径
让一次激活只产生一次副作用，并在物件上可见。
- 按钮默认可激活；鼠标
pointerdown与键盘 Space/Enter 按下时给瞬时下压反馈，松开立即结束。 - 激活后立刻
disabled并设aria-busy="true"，把按钮锁死，让重复点击无法触发新请求。 - 提交中在按钮上显示「提交中…」，完成后切到「✓ 已提交 · 再次提交」并恢复可激活；每次结果都带文字，不只靠颜色。
- 业务条件不满足时用原生
disabled加原因文案，让按钮自动退出 Tab 顺序；绝不靠灰色伪装禁用。
正反例：同一提交按钮，只改一处
围绕同一个提交动作，只改变「提交中如何阻止重复」，看用户后果如何不同。
视觉发灰但没设 disabled，第二次点击照常触发提交；键盘也能再次激活。连点几下就重复下单、重复扣款——灰色不是状态，disabled 才是。
快速自测
按钮正在提交中，用户又连点了三下，哪一种实现能防住重复下单？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。