HTML原生约束验证大全

本文深入解析了HTML原生表单约束验证的核心机制，重点揭示了setCustomValidity()作为唯一能真正覆盖默认错误文案并影响表单提交状态的关键方法，强调必须在input和blur事件中每次先调用setCustomValidity('')清空状态再按需设错，否则错误将顽固残留；同时厘清了checkValidity()与reportValidity()的本质区别——前者静默校验，后者主动触发原生气泡提示；并指出validity对象各属性非互斥、需精准判断具体错误类型，避免因自定义错误未及时清除而意外压制required、pattern等内置验证提示——掌握这些细节，才能让原生验证既可靠又可控，告别“设错容易清错难”的陷阱。

setCustomValidity() 是唯一能真正覆盖浏览器默认错误文案、并影响表单可提交性的方法。其他方式（比如 title、placeholder 或 CSS 伪类）都不改变验证状态，也不能阻止提交。

为什么 setCustomValidity('') 必须在每次输入后重置

浏览器不会自动“撤销”你设过的自定义错误；一旦 input.setCustomValidity('手机号格式错误') 被调用，该字段就进入 validity.customError === true 状态，直到你显式调用 setCustomValidity('')。如果只在 blur 时设错、却不处理“输入变正确后”的清空逻辑，用户改对了内容，错误提示和提交阻断依然存在。

• 必须在 input 和 blur 两个事件里都监听，且每次都先执行 input.setCustomValidity('')
• 再根据当前值判断是否需要设新错误文案，例如：/^\d{11}$/.test(input.value) || input.value === ''
• 别在 submit 事件里统一设置——此时浏览器已触发原生气泡提示，且部分字段可能已跳过验证流程

checkValidity() 和 reportValidity() 的关键区别

checkValidity() 只返回布尔值，不触发任何 UI 提示；reportValidity() 不仅返回布尔值，还会主动唤起浏览器默认的错误气泡（类似用户点击提交但失败时的效果），且只对 :invalid 元素生效。

• 想静默校验（比如用于防抖后的实时反馈），用 checkValidity()
• 想手动触发浏览器原生提示（比如表单提交被拦截后聚焦首个错误项），用 reportValidity()
• reportValidity() 不会冒泡，也不会触发 invalid 事件，它只是 UI 层面的“展示动作”

如何让 validity 对象的判断更可靠

input.validity 是只读对象，但它的各属性（如 valueMissing、patternMismatch）不是互斥的。比如一个空的 required 字段，valueMissing 和 valid 都为 true，但 typeMismatch 为 false；而一个非空但不符合 pattern 的字段，patternMismatch 为 true，valueMissing 为 false。

• 不要只依赖 !input.validity.valid 做分支，应具体检查哪个属性为 true
• validity.badInput 在用户输入了 type 不支持的值时才为 true（如在 type="number" 中输入字母）
• validity.tooLong / validity.tooShort 仅在设置了 maxlength / minlength 且实际长度越界时触发，与 pattern 无关

最容易被忽略的是：自定义错误文案一旦设置，就会压制所有其他内置错误类型（包括 required 和 pattern 的原始提示），哪怕你只设了一次且没清空。所以每个字段的验证逻辑必须闭环——有设，就有清。

终于介绍完啦！小伙伴们，这篇关于《HTML原生约束验证大全》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！