Chrome v93+和新版Edge默认强制内置验证，novalidate仅跳过JS校验而非彻底禁用；可靠方案需移除验证属性、submit时setCustomValidity('')清空状态，或用inputmode替代type。
Chrome 和 Edge 对 novalidate 的处理差异
Chrome 从 v93 起默认启用「表单提交时强制运行内置验证」，即使写了 novalidate，只要表单里有 required 或 type="email" 等约束字段，点击提交仍会弹出原生提示。Edge（基于 Chromium 新版）行为一致，但旧版 Edge（EdgeHTML）会严格遵守 novalidate，不触发任何验证。
关键不是浏览器“支持与否”，而是 Chromium 内核版本对 HTML5 表单验证的执行策略发生了变化：现在它把 novalidate 当作「跳过 JS 触发的 checkValidity()」，而非「彻底关闭所有验证逻辑」。
禁用验证的可靠写法（绕过浏览器默认行为）
仅靠 已不可靠。必须配合以下任一方式：
- 移除所有验证属性：
required、minlength、pattern、type="email"等——改用纯 JS 控制； - 在提交前手动清除验证状态：
form.addEventListener('submit', e => { e.preventDefault(); // 清空浏览器缓存的验证标记 Array.from(form.elements).forEach(el => { if (el.willValidate) el.setCustomValidity(''); }); // 后续走自定义逻辑 }); - 用
inputmode替代type（如），避免触发验证但保留软键盘提示。
setCustomValidity('') 为什么比 novalidate 更有效
setCustomValidity('') 直接重置元素的 validity.valid 状态，且 Chrome/Edge 都会尊重该调用结果；而 novalidate 只影响表单级 submit 事件的默认验证流程，不干预单个字段的 willValidate 判定和 UI 提示。
立即学习“前端免费学习笔记（深入）”；
常见误操作：
- 只在表单上加
novalidate，但没清空input的required属性 → 提交时仍卡住； - 调用
setCustomValidity('')后没调用reportValidity()或未触发重绘 → 红框/提示残留； - 在
input上监听blur并设空值，但用户直接点提交按钮 → 依然触发原生校验。
兼容旧版 Edge 和 Safari 的兜底方案
旧版 Edge（18 及以下）和 Safari（iOS 15.4 前）对 novalidate 支持稳定，但对 setCustomValidity 的响应不一致。稳妥做法是：
- 初始化时统一调用
element.setCustomValidity('')； - 提交前再执行一次清空，并显式调用
element.checkValidity()确保状态刷新； - 避免依赖
:invalidCSS 伪类做样式控制，改用 JS 添加/移除 class。
真正难处理的不是「怎么关」，而是「关到哪一层」：字段级验证、UI 提示、submit 阻断、CSS 状态，四者在不同内核中解耦程度不同，必须分层处理。
