原生 required 属性仅对 input（除 hidden/button/submit/reset）、select、textarea 三类元素生效；其校验基于 value.trim()===""，但无法过滤零宽字符等隐藏符号；仅在表单 submit 时触发，受 novalidate、form.submit()、display:none 等影响而失效；条件必填需 JS 动态控制 required 并调用 reportValidity()；服务端必须重复校验。
原生 required 属性能解决 80% 的必填需求，但直接加就完事？大概率会遇到“明明填了却报错”“checkbox 不生效”“空格被放过”这类问题——根源不在属性本身，而在它和浏览器校验逻辑的配合方式。
哪些元素支持 required，哪些根本无效
它只对三类控件起作用：input（除 type="hidden"、type="button"、type="submit"、type="reset"）、select、textarea。其他如 div 包裹的自定义组件、contenteditable 元素，加了也白加。
-
input type="checkbox"或type="radio"加required，表示“该组中至少选一个”，不是“这个 checkbox 必须勾上” -
select要生效，必须有一个value=""的默认选项，比如<option value="">请选择</option>；否则用户没点选时，value 是 undefined，required判定为未填 -
input type="number"空值时 value 是空字符串，required可捕获；但若 JS 赋值为input.value = " "，浏览器仍认为已填（因" ".trim() !== ""不成立）
required 怎么判断“空”：比你肉眼看到的更严格
浏览器内部用的是 element.value.trim() === ""，但这个 trim() 清不掉零宽字符（如 \u200B）、全角空格、换行符。用户粘贴一段带隐藏符号的文本，页面看着有内容，提交却报错。
- 开发调试时别光看页面，直接在控制台执行
document.querySelector('input').value查原始值 - 对关键字段，可在
input事件里做清理：el.value = el.value.replace(/[\u200B-\u200D\uFEFF]/g, '') - 如果业务要求“非空白字符才算填”，仅靠
required不够，得配合pattern或 JS 校验
为什么加了 required 还没反应？常见失效场景
它只在表单 submit 事件触发时校验，不监听输入过程，也不响应 JS 赋值。很多“没反应”其实是生命周期没对上。
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
立即学习“前端免费学习笔记（深入）”；
- 表单加了
novalidate属性，整个原生校验被禁用，required形同虚设 - 用
form.submit()方法手动提交，绕过了表单 submit 事件，校验不触发 - JS 动态设置
input.value后，没调用input.checkValidity()，DOM 状态没更新，视觉上没错误提示 -
input外层被display: none或visibility: hidden隐藏，部分浏览器会跳过该校验（尤其旧版 Safari）
需要条件必填时，required 必须配合 JavaScript
比如“手机号和邮箱至少填一个”“选了‘其他’才要填备注框”，这些逻辑 required 无法表达，只能用 JS 动态控制 required 属性的有无。
- 监听源头字段的
input或change事件，而非blur（避免用户还没输完就触发） - 用
targetField.required = Boolean(sourceValue)开关必填状态，不要用setAttribute/removeAttribute，后者不触发校验状态重算 - 每次修改后，建议主动调用
targetField.reportValidity()，让错误提示立即浮现，而不是等用户点提交 - 注意：动态添加
required后，若用户已填内容，需手动清空自定义错误：targetField.setCustomValidity("")，否则旧错误残留
最易被忽略的一点：所有前端校验都只是体验层补丁，required 挡不住 curl、Postman 或禁用 JS 的请求。服务器端必须重新校验，且规则要和前端一致，否则会出现“前端说可以，后端说不行”的撕裂体验。
