原生约束验证api仅做前端格式和必填检查，无法保障数据完整性；真正防篡改需后端校验+https+csrf token+输入过滤，前端验证仅为体验优化。
原生约束验证 API 不能保证数据完整性，它只做格式和必填检查；真正防篡改、防损坏必须靠后端校验 + HTTPS + CSRF Token + 输入过滤，前端验证纯属体验优化。
为什么 checkValidity() 和 reportValidity() 不等于数据完整性
这两个方法只判断字段是否满足 required、pattern、min/max 等约束，不涉及业务逻辑（比如用户名是否已被注册、密码是否与旧密码重复）、不阻止 JS 修改 DOM、不校验传输过程中的篡改。
-
checkValidity()返回true只代表“当前值符合 HTML 层面的规则”，不代表“这个值在业务上合法” - 用户打开 DevTools，直接执行
input.value = "admin'; DROP TABLE users;--"，再调form.reportValidity()依然可能返回true - 所有约束都可被绕过：禁用 JS、删掉
required属性、用 curl 提交、抓包重放
pattern 和 type="email" 的实际校验能力有多弱
别把它们当安全防线——它们连基础格式都守不住。
-
type="email"允许a@b.c、test@localhost、甚至@.（Chrome 125+ 仍通过） -
pattern="[0-9]{6}"对abc123456def也返回 valid，因为浏览器默认做子串匹配（除非你显式加^$，但 Chrome 会报错） -
type="number"完全忽略pattern，粘贴abc后显示为空，但checkValidity()仍返回true - 中文需显式写进正则：
pattern="[\u4e00-\u9fa5a-zA-Z0-9_]{2,10}"，\w不匹配汉字
setCustomValidity() 必须配对清空，否则永久卡死
这是最容易导致表单无法提交的坑：设错不清理，后续所有输入都无效。
- 错误写法：
input.setCustomValidity("密码需含数字");后没在合法时重置 - 正确节奏是「验证失败 → 设错；验证通过 → 清空」，例如在
blur或input里： if (!/^(?=.*\d)/.test(this.value)) { this.setCustomValidity("密码需含数字"); } else { this.setCustomValidity(""); }-
setCustomValidity("")是唯一清空方式，delete input.validationMessage无效
想接近“完整性”，至少得补这三件事
原生 API 只是起点，真要降低脏数据入库概率，得叠加这几层：
- 提交前用
fetch调用轻量级后端接口校验唯一性（如用户名是否存在），并用AbortController防止连点 - 所有敏感字段（密码、邮箱、手机号）在 submit 事件中手动提取、trim()、再校验，避免空格干扰
- 给
<form></form>加novalidate，自己用checkValidity()+ 自定义提示统一控制反馈样式和焦点逻辑
记住：任何客户端校验都只是第一道筛子，漏掉的永远比拦住的多。真正决定数据能不能进数据库的，只有后端那一行 if (isEmailValid($input)) 和数据库的 CHECK 约束。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
