原生表单验证仅在submit时触发，需手动介入生命周期；空值判定为value.trim()===""，空格、零宽字符等易被忽略；pattern仅对部分type生效且需锚点，blur实时校验须用checkvalidity/reportvalidity；novalidate仅作用于form元素。
原生表单验证不是加了 required 就自动“实时报错”，它只在提交（submit）时触发，且对 JS 赋值、隐藏字段、空格输入等场景完全无感——想真正控住体验，必须手动介入验证生命周期。
为什么填了内容还提示“请填写此字段”
浏览器判断“空”的逻辑非常朴素：input.value.trim() === ""，但很多情况肉眼难辨：
- 用户只敲了空格、Tab 或粘贴进零宽字符（
u200B），.trim()清不掉 -
<select></select>的首项写成<option value="">请选择</option>，value 为空就直接触发required拒绝 - 用 JS 直接赋值如
input.value = " "，不会触发校验，也不会变:invalid
实操建议：开发时在控制台执行 document.querySelector('input').value 看原始值，比盯着页面猜更准；对关键字段，可在 input 事件里主动调用 setCustomValidity("") 清状态，再做自定义判断。
pattern 正则总匹配失败？锚点和类型限制是关键
pattern 只对 type="text"、"email"、"tel"、"password" 等生效，对 type="number" 或 "date" 完全无效。而且它默认是全字符串匹配，但很多人漏掉语义严谨性：
- 写
pattern="[0-9]{11}"允许"abc12345678901def"通过——必须写成pattern="^1[3-9]d{9}$" -
pattern不校验空值，空值由required控，两者要共存才完整 - 别用
d，部分旧安卓 WebView 解析异常；改用[0-9]或[\d]（双反斜杠转义） - 中文匹配慎用
u4E00-u9FA5，推荐[u4e00-u9fa5]（小写十六进制，无反斜杠）
顺手加 title="请输入11位手机号"，能让错误提示更友好，且不依赖 JS。
怎么让验证在离开字段时就反馈，而不是等提交
原生行为只在 submit 时触发，想实现 blur 或 input 实时校验，必须调用 DOM 方法：
-
checkValidity()返回布尔值，不显示提示，适合做逻辑判断 -
reportValidity()才会弹出浏览器默认气泡，但注意：Firefox 不滚动到错误字段，Chrome 会 - 对单个元素用：
document.querySelector('#phone').reportValidity() - 对整个表单用：
form.reportValidity()，会校验所有带约束的子元素 - 若要自定义文案，必须先
input.setCustomValidity('手机号格式错误')，再调reportValidity()；清空提示必须用setCustomValidity('')，否则后续永远报错
别在 invalid 事件里直接设错误——它只在浏览器判定失败后触发，已晚；应在 input 或 blur 里做主动判断 + setCustomValidity。
novalidate 属性加在哪？很多人第一步就错了
novalidate 是 form 级开关，只对 <form novalidate></form> 生效。加在按钮或 input 上完全无效：
- ❌ 错误：
<button novalidate>提交</button>或<input novalidate> - ✅ 正确：
<form novalidate>...</form>
启用后，所有原生校验（required、type、pattern）全部失效，你得 100% 自己用 JS 补齐空值、格式、异步查重等逻辑。好处是能规避某些低端安卓 WebView 的气泡卡顿，代价是复杂度陡增——除非真有兼容性问题，否则不建议关。
最易被忽略的一点：CSS 伪类 :valid 和 :invalid 在字段**首次交互前默认是 :valid**，哪怕它带 required。也就是说，用户还没点过那个输入框，边框不会变红。想一打开就提示必填？只能靠 JS 主动触发 checkValidity() 并结合 class 控制样式。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
