表单验证需手动调用checkValidity()触发浏览器原生UI反馈，否则required、type="email"等约束不显示红框或提示；setCustomValidity()设非空字符串表示失败并覆盖默认文案，设空字符串才能清除错误；实时校验应监听input和blur事件而非invalid事件。
表单提交前用 checkValidity() 触发原生验证
浏览器自带的 required、type="email" 等约束不会自动弹出提示，必须手动调用验证方法才能触发 UI 反馈。直接监听 input 或 blur 事件时，不调用这个函数，用户就看不到红框、气泡提示或 :invalid 样式生效。
- 在
input事件里调用element.checkValidity()，可让浏览器立刻渲染错误状态（比如边框变红） - 但注意：它只返回
true/false，不抛错，也不自动显示提示文本；要读取错误信息得看element.validationMessage - 别在每次
input都调用reportValidity()—— 它会强制弹出浏览器默认提示框，体验很打断
setCustomValidity() 控制自定义错误文案
原生验证失败时，浏览器默认提示往往不够友好（比如 “Please fill in this field”）。用 setCustomValidity() 可覆盖它，但规则很关键：空字符串表示“通过”，非空字符串才代表“失败”。
- 写法必须是
input.setCustomValidity("邮箱格式不对")，不是input.setCustomValidity({ message: "..." }) - 一旦设过非空值，该字段就始终处于无效状态，直到再次调用
setCustomValidity("")清除 - 常见坑：忘记清空，导致用户输对了也过不了验证；或者在
input事件里反复设同一错误，但没清空逻辑
监听 invalid 事件不如监听 input + blur
invalid 是冒泡事件，只在表单提交时或显式调用 checkValidity()/reportValidity() 后触发，不适合做实时反馈。
- 实时提示应绑定
input（打字中）和blur（失焦时），再配合checkValidity()和validationMessage -
invalid事件里无法阻止默认行为（它本身就不带 preventDefault），也不能用来拦截输入 - 如果用它来显示错误，大概率会漏掉用户还没提交前的纠错时机
CSS 选中器 :valid / :invalid 的渲染时机
这两个伪类依赖浏览器内部验证状态，而该状态只在调用 checkValidity() 或用户交互（如提交、失焦）后更新，不是纯响应式的。
立即学习“前端免费学习笔记（深入）”；
-
:invalid不会在页面加载完就立即生效，哪怕字段初始为空且带required - 必须触发一次验证（例如用户点一下再移开，或脚本调用
checkValidity()），样式才会切换 - 想让初始状态就有样式？得用 JS 先调一遍
checkValidity()，再靠 CSS 响应
checkValidity() 调用，少一次，UI 就卡住一次。 
