浏览器原生校验需用required和type属性配合checkvalidity()实现可控拦截，setcustomvalidity()可自定义提示但须重置，后端校验不可替代且需前后端规则一致。
用 required 和 type 属性做基础校验
浏览器原生校验最省事，但容易误以为“写了就万事大吉”。required 只对非空生效，type="email" 或 type="number" 仅触发格式提示，不阻止提交——用户点“确定”后仍会发请求。
常见错误：把 type="number" 当成数值范围控制，结果输入 abc 被拦住，但输 1e5 或负数却通过了。
-
type="email"不验证邮箱真实性，只检查是否含@和域名结构 -
min/max对type="number"有效，但对type="text"无效 - 所有原生校验都依赖
form的novalidate属性未开启（默认不开启）
监听 submit 事件并调用 checkValidity()
这是可控性最强的前端拦截方式。重点不是阻止默认行为，而是先让浏览器跑一遍内置校验逻辑，再决定是否放行。
典型写法：
form.addEventListener('submit', (e) => {
if (!form.checkValidity()) {
e.preventDefault();
return;
}
// 校验通过，可继续提交或手动发送
});
注意：checkValidity() 会触发每个字段的 invalid 事件，并显示浏览器默认提示气泡；如果页面已有自定义提示，建议加 e.preventDefault() 后统一处理。
- 必须在
submit事件里调用，不能在click上对按钮做判断 -
checkValidity()返回false时，对应字段的validity.valid为false，可进一步查validity.typeMismatch等属性定位原因 - 若表单含动态增删字段，每次操作后需确保新字段也设置了
required或其他约束
用 setCustomValidity() 替换默认提示文本
浏览器原生提示太生硬，比如英文 “Please fill in this field”，中文环境基本不可用。用 setCustomValidity() 可接管提示内容，但有隐藏陷阱。
关键规则：传入空字符串 '' 表示“校验通过”，传入非空字符串表示“校验失败”且显示该文字。
- 必须在每次校验前重置，否则旧错误会残留：
input.setCustomValidity('')应作为第一步 - 不能只靠
input.addEventListener('input', ...)设置，要结合blur和submit两次触发 - 如果多个字段共用同一套规则（如密码确认），需在两个字段上分别调用
setCustomValidity()，否则只有焦点字段提示生效
后端校验不可跳过，前端只是体验层
所有前端校验都可被绕过：禁用 JS、改 DOM、直接 POST 请求。真正能信任的只有服务端返回结果。
实际开发中容易忽略的点：
- 前后端正则不一致，比如手机号校验：前端用
^1[3-9]\d{9}$，后端漏了19号段，用户提交成功但数据异常 - 提交后服务端返回 400 错误，前端没解析
response.body中的具体字段错误，只显示“提交失败” - 异步提交时没清空上次的错误状态，导致旧提示和新提示叠加
复杂点在于：表单字段多、嵌套深、错误码语义不统一。这时候前端需要约定好错误响应结构（如 { field: 'email', message: '邮箱已被注册' }），再映射到对应 DOM 节点——这步没法靠原生 API 完成，得自己写逻辑。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
