仅靠 :disabled 伪类不能防止重复提交，它只负责视觉反馈；真正防重提交必须配合 JavaScript 禁用按钮 + 后端 token 校验，而 :disabled 是用户感知“已锁定”的关键一环。
仅靠 :disabled 伪类不能防止重复提交，它只负责视觉反馈；真正防重提交必须配合 JavaScript 禁用按钮 + 后端 token 校验。但 :disabled 是用户感知“已锁定”的关键一环，漏掉它，交互就断层了。
button:disabled 样式不生效？先确认三件事
常见现象：JS 设置了 btn.disabled = true，但按钮颜色、光标没变，用户仍能点——大概率是样式没生效或被覆盖。
- 检查元素是否为原生
button（或input[type="submit"]）：自定义组件（如div+onclick）不支持:disabled，得改用[aria-disabled="true"] - 确认 CSS 选择器优先级：避免写
button[disabled]（属性选择器），统一用button:disabled，否则容易被其他规则覆盖 - 验证 JS 是否真写了
disabled属性：React/Vue 中disabled={isLoading}是绑定属性，但若渲染时没生成disabledHTML 属性（比如值为false或null），:disabled就不会匹配
光标和禁用态分离：为什么不能只靠 cursor: not-allowed
单纯设 button:disabled { cursor: not-allowed; } 很常见，但实际场景中常出问题：JS 设置 disabled 有微小延迟，用户可能在这 10–50ms 内再次点击；或者按钮本身有 :hover 样式，禁用后悬停效果残留。
- 推荐组合写法：
button.is-loading { cursor: wait; pointer-events: none; }——pointer-events: none立即拦截点击，比disabled更快生效 - 加一层降级：
button.is-loading:not(:disabled) { opacity: 0.8; }，确保 JS 还没来得及设disabled时也有灰度反馈 - 显式重置 hover：
button.is-loading:hover { background-color: initial; box-shadow: none; }，避免禁用状态下悬停样式干扰
表单提交流程中 disabled 的时机与顺序
JS 控制 disabled 和 class 的顺序直接影响体验连贯性。常见错误是先改文字再设 disabled，导致按钮在状态切换瞬间仍可点。
立即学习“前端免费学习笔记（深入）”；
- 启用加载态时，必须同步操作：
btn.classList.add('is-loading'); btn.disabled = true; - 恢复时顺序反过来：
btn.disabled = false; btn.classList.remove('is-loading');—— 如果先删 class，CSS 可能短暂回退到未禁用样式，造成可点击窗口 - 注意
fetch的.finally()必须执行恢复逻辑，哪怕请求失败也要放开按钮，否则用户卡死
为什么你写了 :disabled 却还是被绕过？
:disabled 是纯前端视觉层控制，对 Postman、刷新页面、多标签页、脚本调用完全无效。它只是 UX 链条中的一环，不是安全边界。
- 用户刷新页面后，
disabled状态丢失，按钮立刻恢复可点 —— 这正是必须搭配后端 anti-replay token 的原因 - 框架里（如 React）如果只靠
disabled={isLoading}渲染，没配button:disabled样式，用户看不到任何禁用反馈，会误以为没响应而狂点 - 移动端 Safari 对
pointer-events: none支持不稳定，建议始终保留disabled属性作为兜底
真正可靠的防重提交，是 JS 禁用按钮 + :disabled 视觉反馈 + 后端一次性 token 校验三者缺一不可。其中 :disabled 虽然最轻量，却是用户唯一能“看见”的信任信号——它不防攻击，但防焦虑。
