原生表单验证需满足严格前提才生效：button须为type="submit"，禁用display:none/visibility:hidden，novalidate仅对form有效，pattern仅适用于文本类type且不支持^$锚定，实时校验需手动调reportValidity()并清空setCustomValidity()，:valid/:invalid伪类受用户交互影响而非实时响应。
原生表单验证不是“加了属性就自动工作”，它是一套有严格触发条件、依赖 DOM 状态和用户行为的机制。不满足任一前提，整个验证链就静默失效。
为什么点提交按钮没反应、也不报错
最常见原因是提交行为绕过了浏览器原生验证流程：
-
<button>默认是type="button"，完全不触发验证；必须显式写成<button type="submit"> - JS 中调用
form.submit()是纯脚本提交，跳过所有约束检查；应改用form.requestSubmit() - 表单被
display: none或visibility: hidden隐藏时，带required的字段不参与校验 -
novalidate属性如果误加在<button>或<input>上无效；它只对<form novalidate>生效
pattern 正则总匹配失败？先看 type 和触发时机
pattern 只对 type="text"、"email"、"tel"、"url"、"password" 等文本类类型生效；对 type="number" 或 type="date" 完全无效——浏览器会在正则执行前把值转成数字或日期对象。
- 正则本身不能写
^和$，浏览器自动锚定；写了反而报Invalid regular expression - 中文匹配推荐写成
[\u4e00-\u9fa5]（无反斜杠转义），\u4E00-\u9FA5在旧版 Chrome 会解析失败 -
pattern不校验空值，空字段由required控制；两者必须共存才能既防空又防格式错 - 手机号别只写
pattern="\d{11}"，应写pattern="1[3-9]\d{9}"，避免匹配到纯数字乱码
想实时反馈？得手动调 reportValidity()，但要注意副作用
原生验证默认只在 submit 事件中批量触发，不会监听 input 或 blur。要实现实时提示，必须手动介入：
立即学习“前端免费学习笔记（深入）”；
- 在
input或blur事件中调input.reportValidity()，它会弹气泡并触发invalid事件 -
reportValidity()在 Chrome 会自动滚动到错误字段，在 Firefox 不会；若需统一行为，得自己调scrollIntoView() - 每次校验前必须先清空自定义错误：
input.setCustomValidity('')；否则一旦设过非空字符串，后续哪怕输入合法也始终返回validity.valid === false - 不要在
invalid事件里直接调setCustomValidity()，它会无限循环；应在input或blur中判断后设置
:valid 和 :invalid 伪类为什么样式没变
这两个伪类不是“值一变就立刻响应”，而是严重受用户交互影响：
- 初始加载时，未聚焦过的
required字段是:valid状态，哪怕为空；直到用户blur或提交后才可能变:invalid -
validity.valid为true不代表字段“已通过验证”，只是“当前值不违反任何约束”；例如type="email"填a@b.c也返回true - 移动端某些 WebView（如早期 Android 内嵌）会忽略这些伪类；若需稳定样式，建议配合 JS 监听
input+checkValidity()手动切换 class
真正容易被忽略的是：验证状态不是持续计算的，而是按需快照。一个字段是否 invalid，取决于它最后一次被校验时的上下文——包括是否在表单内、是否可见、是否被用户操作过。任何环节断开，就只剩一个“看起来像表单”的 HTML 片段。
