html表单原生验证仅在submit事件触发，依赖required、type、pattern等属性，但需注意生效条件：必须用type="submit"按钮、包裹于form内、pattern须加^$锚定、setcustomvalidity需手动清空状态。
HTML表单验证不是“加几个属性就完事”，它是一套有明确触发时机、状态边界和协作逻辑的机制。原生验证能解决80%基础场景，但一旦你发现required没反应、pattern总通过、或者type="email"放行a@b.c，说明你还没踩中它的行为边界。
为什么required、type、pattern在提交时才生效
浏览器只在原生submit事件中批量检查所有带约束的字段，不监听input.value赋值、不响应blur或input事件——这是设计使然，不是bug。这意味着：
- 用
JS直接设置input.value = "xxx"后，required不会自动重验；必须手动调input.checkValidity()或form.reportValidity() -
type="email"只要含@和至少一个点（如test@x.y）即算合法，不校验域名是否存在或TLD是否有效 -
pattern默认不锚定，pattern="[0-9]+"会误判abc123def为合法；必须写成pattern="^[0-9]+$" - 若表单里混用了
type="button"而非type="submit"，整个原生验证链就断了
如何用setCustomValidity控制错误提示
想覆盖浏览器默认气泡文案、或实现密码一致性这类跨字段逻辑，setCustomValidity()是唯一可控入口。但它有强状态依赖：
- 每次校验前必须先调
input.setCustomValidity("")清空旧状态，否则残留错误会让后续合法输入也卡住 - 仅在
invalid事件中调event.preventDefault()还不够，必须配合setCustomValidity()设新文案，否则reportValidity()仍弹默认提示 - 两个密码框都要分别设：确认密码框校验失败时，要同时给它自己和原始密码框都调
setCustomValidity("密码不一致")，否则用户改完确认框，原始框边框颜色不会变 -
setCustomValidity("xxx")设空字符串""才代表“通过”，设null或undefined无效
怎样让验证在离开字段时立刻反馈
用户填完邮箱就移开焦点，你希望立刻提示而不是等点提交——这得靠reportValidity()主动触发，不能只靠原生行为：
- 对单个字段：绑定
blur事件，调input.reportValidity()；注意Firefox不自动滚动到错误字段，Chrome会 - 对整个表单：用
form.reportValidity()，它会遍历所有子input并统一报错，适合“下一步”按钮场景 - 若需自定义提示位置（比如在字段下方
<span class="error"></span>里写文案），就不能依赖reportValidity()，而应改用checkValidity()+ 手动DOM操作 -
checkValidity()只返回true/false，不弹窗；reportValidity()才触发UI反馈，两者别混用
哪些地方最容易被忽略
真正卡住开发进度的，往往不是语法，而是状态残留和兼容性盲区：
-
novalidate必须写在<form novalidate></form>上，写在<button></button>或<input>上完全无效 - 移动端
type="number"会唤起数字键盘，但允许粘贴字母且不实时拦截——实际业务中建议用type="text"+pattern+ JS拦截input事件 -
:valid/:invalid伪类只响应原生验证结果，不响应JS手动设的setCustomValidity()，除非你同步更新input.validity.customError状态 - IE10+支持
required和type="email"，但不支持pattern和validity.customError，降级方案得提前准备
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
