HTML表单验证多种实现方式及自定义提示信息配置

许多人认为，只要在HTML表单中添加required、type或pattern属性，验证就能自动生效。然而实际开发中常发现这些机制在某些情况下“失效”。问题的根源在于，原生表单验证的触发时机和判断逻辑与多数人的预期存在差异。

简单来说，原生验证仅在表单提交（submit事件）时统一执行，并且高度依赖用户的真实操作。这导致几个典型盲区：例如，通过JavaScript直接给输入框赋值（input.value = 'abc'）不会触发required检查；type="email"允许输入“foo@bar”这类缺少后缀的格式，因为浏览器的格式校验标准很宽松；而pattern="[0-9]{11}"这样的正则，甚至会将“abc12345678901def”这种包含前后字符的字符串判定为合法，原因在于缺少^和$进行完整字符串锚定。

因此，若需稳定控制验证提示的文案与出现时机，必须主动介入，使用setCustomValidity()配合reportValidity()或checkValidity()来接管流程。

required/type/pattern 属性为什么有时不生效

这些属性“失效”的根源在于它们的触发机制。它们仅在表单提交时统一校验，且对以下几种情况无能为力：

• required：只判断值是否为空字符串、select是否未选择、checkbox是否未勾选，对输入内容的合法性不进行任何检查。
• type="number"：允许粘贴字母，输入框虽显示为空，但其value实际变为空字符串，此时调用checkValidity()竟然返回true。
• pattern：若要确保整个字符串严格匹配规则，必须写成pattern="^[0-9]{11}$"，否则可能出现误判。

最关键的是，所有这些属性的校验都绕不开用户手动触发submit这一动作。浏览器不会监听input（输入）或blur（失去焦点）事件来自动给出反馈。

如何用 setCustomValidity() 替换默认提示文案

setCustomValidity()是唯一能覆盖浏览器默认气泡提示文案的接口。但常见误解在于：调用它并不会立即显示提示。其作用是修改元素的validity状态，后续必须配合reportValidity()或表单提交才能触发UI反馈。

• 传入非空字符串（例如setCustomValidity('手机号格式错误')），元素立即被标记为无效状态。
• 传入空字符串setCustomValidity('')，清除自定义错误，将元素状态恢复为“可能有效”。注意，这并不代表通过校验，只是清除了你设置的错误信息。
• 必须在invalid事件中调用e.preventDefault()来阻止默认行为，否则浏览器仍会弹出原生气泡提示。

一个容易被忽略的操作是：当用户开始输入修正错误后，若未及时调用setCustomValidity('')清空旧的提示，该字段会一直处于校验失败状态。以下是一个常见的实践代码：

const phoneInput = document.getElementById('phone');
phoneInput.addEventListener('invalid', e => {
  e.preventDefault();
  if (phoneInput.validity.valueMissing) {
    phoneInput.setCustomValidity('手机号不能为空');
  } else if (phoneInput.validity.patternMismatch) {
    phoneInput.setCustomValidity('请输入11位手机号');
  } else {
    phoneInput.setCustomValidity('');
  }
});
phoneInput.addEventListener('input', () => {
  phoneInput.setCustomValidity(''); // 用户一开始输入，就清空之前的错误提示
});

怎样让验证在离开字段时立刻反馈（而非等提交）

浏览器原生机制不支持在blur或input时实时校验。要实现这一效果，必须手动调用reportValidity()。该方法会触发校验并显示气泡提示。不过，Firefox和Chrome的行为略有差异：Firefox不会自动滚动到错误字段，而Chrome会。

• 对单个input调用：phoneInput.reportValidity()，非常适合在blur（失去焦点）场景下使用。
• 对整个form调用：form.reportValidity()，适合在表单提交前进行批量检查。
• reportValidity()与checkValidity()的核心区别：checkValidity()仅返回布尔值表示是否通过，不显示任何提示；而reportValidity()既执行校验，又负责展示提示。
• 若表单添加了novalidate属性，则reportValidity()也会失效。此时需要完全依靠自己的JavaScript校验逻辑和自定义DOM提示。

禁用原生验证后怎么接管全部逻辑

若决定给form标签添加novalidate属性，意味着彻底关闭浏览器的内置校验（包括required、pattern等全部失效）。随之而来的代价是需要100%自行实现所有验证逻辑：空值判断、格式正则、跨字段一致性（如两次密码输入是否相同），甚至异步唯一性检查（如用户名是否已存在）。

• novalidate属性必须写在form标签上，写在button或input上完全无效。
• 一旦禁用原生验证，checkValidity()方法总是返回true，validationMessage属性也永远为空字符串。
• 推荐的组合方式：使用novalidate，然后在表单的submit事件中手动遍历form.elements，对每个元素调用自己的校验函数。
• 无障碍访问关键点：若自行创建错误提示区域，务必添加aria-live="polite"和role="alert"属性，否则屏幕阅读器无法感知这些错误信息。

最后，有一个最容易被忽略又至关重要的细节：每次调用setCustomValidity()设置错误信息后，必须确保在用户输入合法内容时，再次调用setCustomValidity('')。否则，该字段将永远被锁定在“无效”状态，即便用户已将内容修正正确。这个空字符串调用不是可选项，它是重置元素validity状态的唯一方式。