html原生表单校验够用但仅适用于基础场景，支持required、type、pattern等属性，无法处理需后端或自定义逻辑的校验，需配合setcustomvalidity()、reportvalidity()等api补足。
HTML原生表单校验够用吗
够用，但只适用于基础场景。浏览器自带的 required、type="email"、pattern 等属性能拦截明显错误，比如空提交或邮箱格式不对，但无法处理“两次输入密码不一致”“用户名已存在”这类需后端配合或自定义逻辑的校验。
常见错误现象：submit 事件仍会触发，即使 :invalid 伪类已生效；用户没看到提示，直接点提交就失败；移动端上 title 提示不显示，导致无反馈。
- 使用场景：登录、注册、联系表单等轻量交互，无需复杂状态管理
- 兼容性：所有现代浏览器支持，IE10+ 基本可用，但
setCustomValidity()在 IE 中需手动触发reportValidity() - 性能影响几乎为零，纯声明式，无 JS 开销
怎么用 setCustomValidity() 补足原生能力
当原生规则不够时，必须用 JS 干预。核心是给 <input> 元素调用 setCustomValidity(message)：传空字符串表示“校验通过”，传非空字符串则标记为无效，并在 checkValidity() 或 reportValidity() 时显示该消息。
容易踩的坑：setCustomValidity() 不会自动清除旧错误；如果多次调用且未清空，后续校验可能被残留 message 阻塞；必须搭配 input 或 blur 事件实时更新，不能只在 submit 时检查。
- 必须在每次校验后显式调用
setCustomValidity("")清除成功状态，否则元素一直保持 invalid -
reportValidity()会触发浏览器默认气泡提示，适合提交前兜底；checkValidity()只返回布尔值，适合条件分支判断 - 对密码确认字段，应在第二个
<input>的input事件里比对value，不相等就setCustomValidity("两次输入不一致")
如何避免重复提交 + 校验失败时焦点跳转混乱
用户狂点提交按钮，或校验失败后焦点卡在第一个错误字段却没滚动到可视区，是真实痛点。原生 reportValidity() 会自动聚焦首个无效字段，但不会滚动；而手动 focus() 后不加 scrollIntoView()，用户可能完全看不到错误位置。
使用场景：长表单、响应式页面、有 fixed 导航栏遮挡顶部的布局。
- 提交按钮加
disabled属性防重复，但仅靠 HTML 属性不够——JS 提交前应设btn.disabled = true，成功/失败后再恢复 - 校验失败后，不要只
input.focus()，要input.scrollIntoView({ behavior: "smooth", block: "center" }) - 移动端 Safari 对
scrollIntoView支持较晚（iOS 15.4+），如需兼容更早版本，可降级用input.getBoundingClientRect().top + window.scrollY手动计算并window.scrollTo()
服务端校验结果怎么同步回前端提示
前端再严，也得过服务端一关。用户填了合法邮箱，但后端说“该邮箱已被注册”，这个信息必须透出，且不能覆盖掉前端已有的其他校验提示（比如密码强度不足）。
关键不是“怎么显示”，而是“怎么组织错误状态”。建议把每个字段的错误存成对象，例如 { email: ["邮箱已被注册"], password: ["至少8位"] }，渲染时按字段注入对应 <span class="error"></span>。
- 不要用
alert()或全局弹窗展示服务端错误，破坏表单上下文 - 后端返回的错误字段名必须与前端
name属性严格一致，否则无法映射 - 若后端返回的是非字段级错误（如“网络异常”），应单独显示在表单顶部，而非绑定到某个
<input> - 调用
setCustomValidity()后，记得再调一次reportValidity()，否则浏览器不触发 UI 反馈
setCustomValidity() 设置的状态就丢了，得重新初始化。这问题不报错，但会让校验“突然失效”。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
