required属性仅对可输入且具“空值”语义的表单控件生效，如text、email、number、textarea、select（含空value选项）、checkbox、radio及file等；hidden、button等无效；它仅判空不校验格式，提示不可定制，不能替代服务端验证。
required 属性只对特定表单控件生效
不是所有 <input> 都能用 required 触发浏览器原生验证。它只在用户可输入、且有明确“空值”语义的控件上起作用，比如 type="text"、type="email"、type="number"、textarea、select（必须没设 selected 的默认空选项）、input[type="checkbox"] 和 input[type="radio"]（后者需同 name 下全未选）。
常见误用：给 input[type="hidden"] 或 input[type="button"] 加 required —— 它们压根不参与验证，浏览器直接忽略。
-
input[type="file"]支持required，但空文件选择框会被判为“未选”，注意和“已选但上传失败”区分 -
input[type="date"]、[type="month"]等日期类控件也支持，但 Safari 旧版本可能不触发弹窗提示 -
contenteditable元素即使模拟输入框，加required也无效 —— 它不是原生表单控件
required 不校验内容质量，只判“是否为空”
required 的逻辑极简：对字符串值调用 .trim() 后是否为 ""；对 select 看选中项的 value 是否为空字符串；对复选框/单选框看是否至少有一个被勾选。它不管正则、长度、格式、范围。
例如：<input required type="email"> 并不会真正校验邮箱格式 —— 用户输 "a@b" 或 "@.com" 也能通过 required 检查（但会触发 type="email" 自带的格式验证）。
立即学习“前端免费学习笔记（深入）”；
- 空格字符串
" "被视为“空”，required会拦截 -
select必须配一个<option value="">请选择</option>作为初始项，否则默认选中第一项，required失效 -
input[type="number"]输入字母时，值为""（非"NaN"），required仍按空字符串判断
提交失败时的错误提示不可自定义，但可干预
用户点击提交后，若含 required 的字段为空，Chrome/Firefox 会显示原生气泡提示（如“请填写此字段”），文案由浏览器语言环境决定，无法用 HTML/CSS 修改。
想统一提示或改逻辑？得用 JavaScript 拦截：
form.addEventListener('submit', e => {
if (!form.checkValidity()) {
e.preventDefault();
// 在这里手动聚焦第一个无效项，或显示自定义 Toast
form.querySelector(':invalid')?.focus();
}
});
-
checkValidity()返回false表示有required或其他约束未满足 -
:invalid伪类可选中所有未通过验证的元素，包括required失败项 - 直接修改
setCustomValidity("消息")可覆盖原生提示，但需配合""清空来恢复默认行为
required 和 JavaScript 表单验证不是互斥关系
很多人以为加了 required 就不用写 JS 校验了 —— 这是危险误解。它只是最基础的客户端防护，绕过方式太多：禁用 JS、删掉属性、用 curl 提交、甚至开发者工具临时改 DOM。
真实项目里，required 的价值是提升用户体验（即时反馈），而非替代服务端验证。
- 后端必须重新校验所有字段是否为空，不能信任前端传来的任何值
- 如果字段有业务规则（如“手机号必须为 11 位”），
required完全无能为力，必须靠 JS + 后端双重实现 - 移动端软键盘唤起逻辑有时受
required影响（如 iOS Safari 对空input更倾向弹出数字键盘），属于隐性副作用
required 是最浅的一层，但它一旦配错控件类型、或和 disabled/readonly 混用，就会静默失效 —— 这种问题在线上很难被发现，只能靠人工点检或自动化测试覆盖。 
