checkValidity() 不等于数据完整性校验，因其仅验证 required、pattern 等 HTML 原生约束，无法覆盖业务逻辑（如用户名唯一性）、跨字段规则（如密码一致性）及防篡改，且所有浏览器验证均可被绕过。
HTML表单提交前的数据完整性校验，不能靠 checkValidity() 或 reportValidity() 单独完成——它们只检查 HTML 层面的约束（如 required、pattern），不校验业务逻辑，也不防篡改。
为什么 checkValidity() 不等于完整性校验
这个方法返回 true 仅代表当前值满足 required、minlength、type="email" 等声明式规则，但完全不管：
- 用户名是否已被注册（需异步查库）
- 两次输入的密码是否一致（跨字段逻辑）
- 手机号是否真实可拨通（业务含义）
- 用户是否在 DevTools 里执行了
input.value = "admin'; DROP TABLE users;--"后仍点提交
浏览器原生验证全部可绕过：禁用 JS、删掉 required 属性、用 curl 直传、抓包重放……所以它只是体验层“快筛”，不是安全层“把关”。
提交前必须手动做的三件事
真正降低脏数据入库概率，得在 submit 事件中主动干预，而不是依赖原生行为：
立即学习“前端免费学习笔记（深入）”；
-
所有敏感字段先
.trim()：空格常被忽略，比如邮箱前后带空格会导致后端校验失败或去重失效 -
显式提取并校验跨字段逻辑：例如比对
password和confirm_password值是否严格相等（===，非==） -
对关键字段发起轻量级预检请求：如用户名唯一性，用
fetch(..., { signal: AbortController.signal })防连点，并在响应后调用input.setCustomValidity()设置错误
setCustomValidity() 的坑与正确节奏
这是最容易让表单“卡死”的地方：设错不清理，后续任何合法输入都无效。
- 错误写法：
input.setCustomValidity("密码需含数字")后没清空 → 表单永远无法通过 - 正确节奏是「验证失败 → 设错；验证通过 → 清空」，且必须用
setCustomValidity("")，delete input.validationMessage无效 - 推荐绑定在
input或blur上，而非仅靠submit：用户边输边提示，体验更顺
复杂点在于：业务规则越细，预检请求越多，abort 控制、loading 状态、错误聚类提示就越容易漏。别指望一次写完就稳——它本质是前端对后端能力的“试探性调用”，稳定性取决于接口响应和网络容错设计。
