表单提交时应监听submit事件，先调用checkValidity()或reportValidity()完成原生验证，验证通过后再禁用按钮并发送请求；避免提前禁用按钮或手动调用form.submit()导致校验被绕过。
表单提交后如何禁用提交按钮但保留验证逻辑
禁用按钮本身不会影响 HTML5 表单验证触发，但常见错误是把 disabled 加在 submit 按钮上后，又手动调用 form.submit() —— 这会绕过所有内置校验。真正要解决的是：**验证必须在禁用前完成，且禁用不能干扰验证流程**。
关键点：HTML5 验证只在用户点击可交互的 submit 按钮（或按 Enter）时自动触发；一旦按钮被设为 disabled，它就不再响应点击，也就不会触发验证。
- ✅ 正确做法：监听
submit事件，在event.preventDefault()后手动检查form.checkValidity()，验证通过再禁用按钮 + 发送请求 - ❌ 错误做法：直接给按钮加
onclick="this.disabled=true"，没等验证就禁用，导致空提交或跳过校验 - ⚠️ 注意：
form.reportValidity()会触发校验并显示默认提示，比checkValidity()更适合用户交互场景
防止重复提交但不破坏 required/minlength 等原生校验
原生校验（如 required、type="email"、minlength）依赖表单的“可提交状态”，而这个状态由浏览器控制。只要不提前禁用按钮、不调用 form.submit()，校验就会正常工作。
典型安全提交模式：
立即学习“前端免费学习笔记（深入）”；
form.addEventListener('submit', function(e) {
if (!this.checkValidity()) {
e.preventDefault();
return;
}
// 验证通过，才禁用按钮
const btn = this.querySelector('[type="submit"]');
btn.disabled = true;
btn.textContent = '提交中...';
// 此处发 AJAX 或继续 submit()
});
- 不要在
input或blur时就禁用按钮——这会阻断用户修正输入 - 如果用了
fetch或axios，记得在finally块里恢复按钮（仅当请求失败需重试时） -
form.noValidate = true会彻底关闭原生校验，慎用；禁用重复提交不该以牺牲校验为代价
Chrome/Firefox 中 reportValidity() 不生效的常见原因
reportValidity() 是触发校验并显示气泡提示的最简方式，但它在某些情况下静默失败，比如：
- 目标元素不在文档流中（例如在
display: none的 tab 页里） - 调用时机过早——比如在 Vue/React 的异步更新钩子中未等 DOM 渲染完成
- 表单内有自定义
input组件但没正确设置setCustomValidity('') - 父容器有
pointer-events: none或遮罩层拦截了焦点
调试建议：在控制台手动执行 document.querySelector('form').reportValidity()，看是否弹出提示。如果不弹，说明校验器没识别到有效字段，优先检查 name 属性是否存在、required 是否拼写正确、是否有 aria-hidden="true" 干扰了可访问性树。
服务端返回校验失败后如何恢复按钮并定位错误字段
前端禁用按钮后，若后端返回 400（如邮箱已被注册），仅恢复按钮还不够——用户需要知道哪错了，且原生校验状态已丢失。
- 恢复按钮：直接
btn.disabled = false，改回文字即可 - 重新激活原生提示：对出错字段调用
input.setCustomValidity('邮箱已被使用')，再调用input.reportValidity() - 避免重复提示：调用
setCustomValidity('')清除旧错误后再设新错误 - 聚焦首个错误字段：
input.focus()，配合scrollIntoView({block: 'nearest'})提升体验
复杂点在于：原生校验只管格式，不管业务规则（如“用户名是否可用”）。这类校验必须由服务端返回具体字段和消息，前端再映射回对应 input 元素——没有通用方案，得按接口约定逐个处理。
