HTML5原生required、pattern和type可解决空值、基础格式（如email）、正则匹配等提交时校验，但无实时反馈、提示不可定制；pattern默认子串匹配需显式加^$，type="number"无法阻止非法字符输入。
HTML5 原生 required、pattern 和 type 能解决哪些校验？
能覆盖基础场景，但仅限于提交时触发、无实时反馈、错误提示不可定制。比如 required 对空值拦截有效，type="email" 会检查基本格式（但不验证域名是否存在），pattern 支持正则，但只对字符串生效且不支持标志如 g 或 i。
常见踩坑点：
-
pattern的正则默认**不加 ^ 和 $**，实际匹配的是子串，应显式写成pattern="^[a-z]{3,}$" -
type="number"允许输入e或-，提交时才报错，无法阻止用户键入非法字符 - 所有原生校验在
input失去焦点或表单提交时才触发，无法实现「输入中实时拦截」
用 addEventListener('input') 做实时校验的关键细节
这是最轻量、兼容性好（IE9+）的增强方式，核心是监听 input 事件而非 keyup（后者捕获不到粘贴、拖入、语音输入等）。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 对每个需要校验的
<input>单独绑定，避免用事件委托——因为input事件不冒泡到form - 用
setCustomValidity()控制原生报错状态：input.setCustomValidity('手机号格式不对')，清空时必须调用input.setCustomValidity('') - 不要直接改
input.value来“修正”内容（如自动加空格），这会导致光标跳到末尾；改用input.setSelectionRange()保留光标位置
示例：手机号实时校验
const phoneInput = document.querySelector('#phone');
phoneInput.addEventListener('input', () => {
const val = phoneInput.value.replace(/\D/g, '');
if (val.length === 11 && /^1[3-9]\d{9}$/.test(val)) {
phoneInput.setCustomValidity('');
} else {
phoneInput.setCustomValidity('请输入正确的11位手机号');
}
});
为什么 checkValidity() 和 reportValidity() 行为不同？
checkValidity() 只返回布尔值，不触发 UI 提示；reportValidity() 会触发浏览器默认气泡提示，并滚动到首个无效字段——但这个提示样式无法修改，且在 Safari 中可能不显示。
使用场景差异：
- 表单提交前主动调用
form.checkValidity()判断是否可发请求，避免多余 AJAX - 调试时用
reportValidity()快速看哪个字段没过，但上线后建议禁用它，改用自定义提示 - 注意：如果字段有
setCustomValidity('')，checkValidity()才返回true；哪怕 DOM 属性写了required，只要 JS 设置了非空字符串，就始终返回false
服务端校验不可省略，前端只是体验层
所有前端校验都可被绕过：禁用 JS、删掉 required 属性、手动构造 POST 请求。所以 email 字段仍需服务端验证 MX 记录，password 仍需服务端检查强度规则，username 仍需查重。
容易被忽略的点：
- 前后端正则要完全一致，比如前端用
/^[a-zA-Z0-9_]{3,16}$/，后端不能漏掉下划线或长度上限 - 提交时若用
fetch发送 JSON，别忘了把FormData转成对象再序列化，否则空值可能变成undefined而非字符串'' - 后端返回的错误字段名（如
field: "phone"）最好和 HTML 的name属性严格一致，方便前端快速定位并高亮
校验逻辑越靠近用户操作点，体验越顺滑；但真正可靠的边界永远在服务端。
