setCustomValidity()是唯一能覆盖默认错误文案并影响提交性的方法；必须在input和blur事件中每次都先调用setCustomValidity('')再判断设错，否则错误状态持续存在。
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 的原始提示），哪怕你只设了一次且没清空。所以每个字段的验证逻辑必须闭环——有设，就有清。
