required属性失效最常见的原因是表单提交被JavaScript阻断且未调用checkValidity()，或元素被设为display:none、visibility:hidden、移出DOM、写在非表单控件上、有默认值、为type="hidden"或disabled。
为什么 required 属性没起作用？
最常见原因是表单提交被 JavaScript 阻断但未显式调用 checkValidity()，或元素本身被动态移出 DOM、设为 display: none 或 visibility: hidden —— 浏览器会跳过对不可见/不可交互元素的原生验证。
其他典型场景包括：
-
required写在了非表单控件上（比如<div required>），它只对<input>、<select>、<textarea>有效 - 输入框有默认值（哪怕空格），
value不为空字符串，required就不会触发 - 用了
type="hidden"或disabled，即使带required也会被忽略 - 表单提交通过
form.submit()调用（而非用户点击 submit 按钮），此时不触发原生验证
如何真正禁用 required 验证？
禁用方式取决于你想“临时绕过”还是“彻底移除”验证逻辑：
- 运行时移除：用
element.removeAttribute('required')，之后再调用element.checkValidity()会返回true - 临时跳过：给
<form>加novalidate属性，整个表单原生验证失效（但 JS 仍可手动调用checkValidity()） - 条件性启用：用 JS 动态设置
element.required = false，注意这和removeAttribute效果一致，但更易维护状态 - 避免误触发：如果只是想隐藏字段又保留验证，改用
aria-hidden="true"+style="position: absolute; left: -9999px;"，别用display: none
checkValidity() 和 reportValidity() 的区别
两者都返回布尔值，但行为差异直接影响调试体验：
根据ui图生成前端页面
下载
将一个或多个 UI 原型图、线框图、产品截图或设计稿转换为标准化、可直接交付的 PRD 风格文档，供产品、设计、前端和测试共同使用。适用于 Codex 需要分析 PC 网页、桌面端、移动端、响应式页面、独立弹窗、表单、表格、看板、数据大屏或多页面流程截图，还原页面结构与交互，强制套用固定文档模板，抽取跨页面共享规则，或把一组原型沉淀为单页规范文档加整体业务流程文档的场景。不适用于纯视觉审美点评、代码实现、接口设计、埋点方案、竞品分析或无 UI 输入的业务需求创作。
立即学习“前端免费学习笔记（深入）”；
-
checkValidity()只检查，不显示浏览器默认错误提示，适合静默校验或组合多个字段逻辑 -
reportValidity()在检查后自动弹出气泡提示（如 “请填写此字段”），且会触发invalid事件，适合用户主动提交时反馈 - 注意：若元素被
disabled或不在 form 内，两个方法都返回true（视为无需验证） - 在自定义 submit 处理中，应优先用
reportValidity()，否则用户看不到任何提示
移动端 Safari 和旧版 Edge 的兼容性坑
required 原生支持虽广，但表现不一：
- iOS Safari 15.4 之前，
input[type="date"]+required在未选日期时可能不报错（需手动reportValidity()） - 旧版 Edge（EdgeHTML）对
fieldset[disabled]内的required元素验证行为异常，建议避免嵌套禁用 - 部分安卓 WebView（如 Android 7-9 系统自带）忽略
required对contenteditable区域的限制，这类场景必须靠 JS 补充校验 - 所有浏览器均不校验
value含不可见字符（如 、\u200b）的情况，前端清洗输入比依赖required更可靠
原生验证只是第一道防线，关键字段始终要服务端二次校验；required 失效往往不是 bug，而是你没意识到它根本没被浏览器“看见”。
