novalidate 属性仅在 form 标签上有效，禁用原生提交校验但不影响语义、键盘类型及伪类初始匹配；formnovalidate 在部分 Safari 和 WebView 中静默失效；reportValidity() 会绕过 novalidate。
novalidate 属性只在 form 标签上才起作用
浏览器原生验证拦截是否生效，取决于 novalidate 是否写在 标签上。加在 、 或其他任何标签上都完全无效——浏览器会静默忽略，既不报错也不触发任何行为。
常见错误包括：
-
no-validate（拼写含连字符，HTML 不识别） -
noValidate（JS 驼峰写法，仅适用于 React/Vue 等框架的 props，最终渲染到 DOM 必须是小写novalidate） -
（布尔属性不接受值，写了也当true处理）
正确写法只有两种：（推荐）或 （空字符串合法但易误解）。
formnovalidate 按钮级豁免在 Safari 和旧 WebView 中不可靠
formnovalidate 是按钮级开关，只对 或 有效，但它在 Safari ≤ 14.1、iOS 15.4–17.x 及部分 Android WebView（尤其 Android 9 及更早）中存在静默失效问题：点击按钮后仍弹原生提示、焦点卡在第一个必填字段。
这不是代码写错了，而是浏览器实现缺陷。实操建议如下：
- 关键路径（如“暂存草稿”）别单独依赖
formnovalidate，优先用+ JS 手动控制提交逻辑 - 若必须用
formnovalidate，需兜底监听submit事件：e.preventDefault(); e.target.form.submit(); - 避免使用
form.requestSubmit()—— 它会无视formnovalidate，重新触发校验 - 测试时务必在真机 Safari 和企业微信/钉钉内嵌 WebView 中验证，不能只看 Chrome/Firefox
加了 novalidate 后，CSS 伪类和键盘类型仍照常工作
novalidate 只禁用“提交时的自动校验拦截”，不影响语义和交互层。这意味着：
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
-
required、type="email"、pattern等属性保留在 DOM 中，读屏器仍会读作“必填项”，移动端仍唤起邮箱键盘或数字键盘 -
:valid/:invalid伪类**不会实时更新**：浏览器不再跟踪字段有效性状态，所以初始为空时可能匹配:invalid，但输入内容后也不会自动切到:valid - 如果你用了
input:invalid { border-color: red; }，红边框可能一直挂着——这不是 bug，是预期行为；要清除它，得用 JS 主动移除 class 或重置setCustomValidity('')
别指望 novalidate 自动帮你清理样式或状态，它只交出控制权，不代劳任何事。
第三方库调用 reportValidity() 会让 novalidate 形同虚设
novalidate 只拦住用户点击提交时的自动校验，但拦不住你或第三方库（如 VeeValidate、Formik、自定义表单组件）主动调用 reportValidity()。这个方法会无视 novalidate，强制弹出原生气泡提示。
调试时容易踩坑的点：
- 全局搜索项目中所有
reportValidity()调用，尤其是 blur、input、submit 事件监听器里 - 检查是否启用了库的
enableNativeValidation选项（VeeValidate 默认开启） - 临时注释掉所有
reportValidity()，确认是否还弹窗；再逐个放开定位源头 - 可在 submit 处理函数开头加判断：
if (form.hasAttribute('novalidate')) return;，防止误触发
真正难处理的是：novalidate 下 ValidityState 对象仍在计算，但 UI 反馈（伪类、边框、焦点）不同步——这个细节往往要调试半天才意识到。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
