required仅触发浏览器原生空值验证，不阻止提交且不可替代后端校验；它依赖type="submit"触发，对hidden/button等无效，select需避免空value占位符，textarea认为空格换行无效，自定义组件需js手动检查，提示样式受限，后端必须独立校验空值。
required 属性只触发浏览器原生验证，不自动阻止表单提交
加了 required 不代表表单就“安全”或“一定校验成功”。它只是告诉浏览器：这个字段不能为空，但实际是否拦截提交，取决于用户如何触发提交（比如按回车、点按钮）、浏览器是否支持、以及有没有其他 JS 干扰。
常见错误现象：required 字段留空却仍能提交，通常是因为用了 type="button" 而非 type="submit"，或者绑定了 event.preventDefault() 却没手动检查有效性。
- 必须用
<button type="submit"></button>或<input type="submit">触发原生验证 - 如果用 JS 监听
click事件并调用form.submit()，会绕过required校验 -
required对type="hidden"、type="button"等无效
input 和 select 都支持 required，但 textarea 和自定义组件需额外注意
required 是全局属性，所有可填写的表单控件理论上都支持，但行为有差异：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
-
<input required>：空字符串、未选中 radio、未选中 checkbox（未勾选）都会失败 -
<select required></select>：必须有一个<option></option>带selected且值非空；首项不能是空值占位符（如<option value="">请选择</option>），否则会被视为“已选择空值”，校验通过 -
<textarea required></textarea>：只校验是否为空字符串，换行符\n或空格不算“有内容”，但用户肉眼可能看不出 - 自定义组件（如用 div 模拟下拉）完全不响应
required，得靠 JS 手动检查element.checkValidity()
验证失败时的提示和样式控制很有限
浏览器默认会在 invalid 元素上添加 :invalid 伪类，并在提交时弹出气泡提示（内容不可定制）。但你没法用 CSS 改变气泡文字，也不能统一拦截所有提示逻辑。
- 可用
:invalid:not(:placeholder-shown)区分“真无效”和“刚聚焦还没输”的状态，避免误标 - 用
setCustomValidity("错误信息")可覆盖默认提示，但必须配合reportValidity()或提交触发才显示 - 调用
checkValidity()返回布尔值，不触发 UI 提示；reportValidity()才会弹气泡 - Chrome/Firefox 的提示位置、延迟、关闭方式都不一致，别依赖它的 UX
required 不等于数据有效，后端必须重新校验
前端 required 完全可被禁用（禁用 JS、修改 DOM、curl 提交），它只提供基础体验优化。哪怕用户没删属性，也可能填 “ ”、"N/A"、"123"（但期望是邮箱）——这些都不是 required 能管的。
-
required只检查“是否为空”，不检查格式、长度、范围、唯一性等 - 服务端收到请求时，必须独立执行空值判断，不能信任
req.body.xxx !== undefined就认为存在 - Node.js 中常见坑：
req.body.field可能是""、" "、null、undefined，需用!field?.trim()类似逻辑判断
最常被忽略的是：很多人以为加了 required 就不用写后端空值校验了，结果上线后接口频繁 400 —— 因为用户用 Postman、脚本或禁用 JS 的浏览器直接绕过了所有前端约束。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
