原生HTML表单校验需手动介入生命周期，因required仅submit触发且对空格、零宽字符、JS赋值无感；验证逻辑为input.value.trim() === ""，但trim不处理零宽字符等；pattern仅对部分type生效且需锚点，blur实时校验需checkValidity与reportValidity配合，setCustomValidity传空字符串才表示通过。
原生 HTML 表单校验不是加了 required 就能“实时报错”，它默认只在 submit 时触发，且对空格、零宽字符、JS 赋值等场景完全无感——想控住体验，必须手动介入验证生命周期。
为什么填了内容还提示“请填写此字段”
浏览器判定“空”的逻辑极简：input.value.trim() === ""，但很多输入肉眼不可见：
- 用户只敲了空格、Tab 或粘贴进零宽字符（
\u200B），.trim()清不掉 -
<select>首项写成<option value="">请选择</option>，value 为空就直接触发required拒绝 - 用 JS 直接赋值如
input.value = " "，不会触发校验，DOM 状态也不会变:invalid
实操建议：开发时在控制台执行 document.querySelector('input').value 看原始值，比盯着页面猜更准；对关键字段，可在 input 事件里主动调用 setCustomValidity("") 清状态，再做自定义判断。
pattern 总匹配失败？锚点和类型限制是关键
pattern 只对 type="text"、"email"、"tel"、"password" 等生效，对 type="number" 或 "date" 完全无效。而且它默认是全字符串匹配，但很多人漏掉语义严谨性：
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 写
pattern="[0-9]{11}"允许"abc12345678901def"通过——必须写成pattern="^1[3-9][0-9]{9}$" -
pattern不校验空值，空值由required控，两者要共存才完整 - 别用
\d，部分旧安卓 WebView 解析异常；改用[0-9]或[\d]（双反斜杠转义） - 中文匹配慎用
\u4E00-\u9FA5，推荐[u4e00-u9fa5]（小写十六进制，无反斜杠）
顺手加 title="请输入11位手机号"，能让错误提示更友好，且不依赖 JS。
怎么让验证在离开字段时就反馈，而不是等提交
原生行为只在 submit 时触发，想实现 blur 或 input 实时校验，必须调用 DOM 方法：
-
checkValidity()返回布尔值，不显示提示，适合做逻辑判断 -
reportValidity()才会弹出浏览器默认气泡，但注意：Firefox不滚动到错误字段，Chrome会 - 推荐组合：在
blur时调用checkValidity()判断，再配合setCustomValidity()设定或清空消息；仅在真正需要视觉提示时调用reportValidity()
别忘了给 <form> 加 novalidate 属性——否则 submit 仍会触发原生弹窗，干扰你自己的逻辑。
setCustomValidity 的坑：空字符串才是“通过”
setCustomValidity() 是个“开关型”API：传入非空字符串即标记为无效，传入空字符串（""）才表示通过。这跟大多数布尔逻辑相反，极易踩坑：
- 误写
input.setCustomValidity(null)或undefined，会导致字段永久 invalid（浏览器把它当字符串"null"处理） - 在
input事件中频繁设值，但忘记在合法时重置为""，会导致后续submit卡死 - 多个校验规则共存时（如长度 + 正则），需合并判断后统一调用一次
setCustomValidity()，不能分头设
复杂点在于：它不自动清除，也不响应 value 变化——你得自己管好时机和清空逻辑，这点比写个 if/else 还容易漏。
