用 novalidate 属性可彻底关闭表单原生验证，只需在 标签中添加 novalidate（如 ），它优先级最高、无需 JS、仅作用于当前表单。
怎么用 novalidate 彻底关掉整个表单验证
HTML5 表单默认会触发原生校验（比如 required、type="email"），提交时弹红框+提示。想临时绕过，最直接的方式是给 <form></form> 加 novalidate 属性——它不依赖 JS，优先级最高，连浏览器右键“检查元素”后手动删掉 required 都不如它干脆。
常见错误现象：只在 input 上加 disabled 或 readonly，结果提交时仍被拦住；或者只用 JS 绑定 event.preventDefault()，但没阻止原生校验的 UI 干预（比如焦点跳转、自动聚焦第一个错误项）。
-
novalidate是布尔属性，写成<form novalidate></form>或<form novalidate=""></form>都行，不用赋值 - 它只影响当前
<form></form>，不影响页面其他表单 - 开发调试时建议加在模板里（如 Vue/React 的 JSX 或服务端渲染输出），别靠 JS 动态加——避免闪现校验失败态
Chrome DevTools 里临时禁用验证的快捷方式
不是每次改代码都方便，尤其线上环境或第三方系统嵌入的表单。Chrome 开发者工具可以直接停用 HTML5 表单验证逻辑，比改 DOM 更快。
操作路径：打开 DevTools → 右上角三个点 → More tools → Sensors → 勾选 Disable form validation。这个开关只对当前 tab 生效，刷新后保留，关闭 tab 就失效。
立即学习“前端免费学习笔记（深入）”；
- 该选项本质是让 Chrome 忽略所有
checkValidity()调用和原生 UI 提示，但validity对象本身还在（JS 里读input.validity.valid仍是false） - Firefox / Safari 没对应内置开关，得靠控制台执行
document.querySelectorAll('input, select, textarea').forEach(el => el.setCustomValidity("")) - 注意：勾选后，
submit事件仍会触发，只是不卡住提交流程
JS 层面绕过校验但保留表单逻辑的写法
有些场景不能动 HTML（比如 CMS 后台生成的表单），也不能依赖 DevTools（要分享给同事复现），就得用 JS 干预。核心思路是「不让浏览器走默认校验链路」，而不是暴力清空 validity。
关键动作是监听 submit 事件并调用 event.preventDefault()，同时确保没有其他地方调用 form.reportValidity() 或 input.checkValidity()。
- 不要只监听
clickon button：用户可能回车提交，或调用form.submit()方法，这些都绕过 click - 推荐写法：
form.addEventListener('submit', e => { e.preventDefault(); /* 你的逻辑 */ }); - 如果已有 submit 处理函数，检查是否漏了
e.preventDefault()—— 这是最常踩的坑，尤其用了 jQuery 的$('form').on('submit', ...)却忘了return false或e.preventDefault()
服务端返回 400 时前端还校验？那是前后端校验错位
禁用前端校验不是为了放弃数据质量，而是为调试腾出空间。但如果关掉后，服务端频繁返回 400 Bad Request，说明校验责任没理清。
典型错位：前端用 type="number" 限制输入，但服务端仍收到字符串 "123abc"；或前端没校验长度，服务端却因超长字段报错。这类问题禁用前端验证只会掩盖协作漏洞。
- 前后端必对齐的最小校验集：非空（
required）、格式（email/url）、长度（minlength/maxlength） -
pattern正则尽量简单，避免和后端正则不一致（比如前端用/^\d+$/，后端用^\d{1,10}$） - 真正该由前端承担的，是即时反馈（比如邮箱格式错立刻标红），而不是代替服务端做最终判定
复杂点在于：禁用验证容易，但判断「此刻该不该禁」很难——是接口联调阶段？还是压测时批量造数？不同场景下，novalidate、DevTools 开关、JS 阻断这三招得切换着用，别锁死一种。
