必须组合html5属性+javascript约束验证api+服务端兜底才能可靠验证；html5仅做基础格式校验，js用于跨字段比对和异步校验，服务端必须独立验证所有输入。
原生 required 和 type="email" 这类属性只能拦住最表层的输入错误，真要防用户乱填、绕过、或做业务级判断（比如两次密码不一致、用户名已存在），必须组合 HTML5 验证属性 + JavaScript 约束验证 API + 服务端兜底 —— 少一层都可能出问题。
用 HTML5 属性做第一道过滤
浏览器会在提交前自动触发这层校验，不写 JS 就有基础防护，但仅限格式和必填逻辑：
-
required是最轻量的必填控制，但只检查是否为空字符串，不处理空格或全角空格 -
type="email"会校验是否含@和.，但不会验证域名是否存在（test@x也能过） -
minlength="6"对<input type="password">有效，但对type="text"在 Safari 旧版中可能被忽略 -
pattern必须配合title属性，否则 Chrome 不显示自定义提示文本；正则末尾别加$，否则带空格的输入容易误判
用 checkValidity() 和 setCustomValidity() 补业务逻辑
当需要跨字段比对或调用接口时，得靠 JavaScript 主动干预验证状态，而不是只靠 onsubmit + preventDefault() 手动拦截：
- 在
input或blur事件里调用pwdConfirmInput.checkValidity()，能实时触发校验并更新:invalid状态 - 校验失败时，必须调用
pwdConfirmInput.setCustomValidity("密码不一致")；成功时一定要设为空字符串setCustomValidity("")，否则后续checkValidity()永远返回false - 不要在
submit事件里重复调用setCustomValidity后再checkValidity()—— 浏览器已自动触发，重复调用反而干扰原生提示时机 - 若需异步查重（如用户名是否可用），得先
setCustomValidity("检查中...")，等接口返回后再更新为错误或清空
为什么不能只信前端验证
所有前端校验都能被禁用、绕过或篡改：
- 用户可右键审查元素，直接删掉
required或pattern属性 - 用 curl 或 Postman 发送请求，完全跳过浏览器校验逻辑
- JavaScript 可被禁用，
setCustomValidity失效，checkValidity()不执行 - 即使前端做了完整校验，服务端仍需独立验证：长度、类型、SQL 注入、XSS 过滤、业务唯一性（如手机号是否已被注册）
最容易被忽略的是「校验状态残留」：比如用户输错密码确认，JS 设置了 setCustomValidity("不一致")，但没在密码框内容变化后及时清空，导致后续输入正确也一直报错。每次修改输入值后，都要主动重置自定义错误状态。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
