required仅作基础空值拦截，不校验内容合法性、不防绕过、无自定义提示、不支持联动与异步校验，仅适用于防手滑的轻量辅助场景。
required 属性不能替代校验规则，它只是最基础的客户端空值拦截，绕过简单、无语义、不防提交。
为什么 required 不能当校验用
它只检查控件是否有用户输入（对 <input> 类型而言），不关心内容是否合法。比如邮箱字段加了 required，用户填 abc 也能通过；数字字段填 123abc 同样能提交——浏览器根本不校验格式或类型。
更关键的是，required 完全依赖 HTML 表单原生行为，一旦用户禁用 JS、手动删掉属性、或用 POST 工具直接发请求，后端照样收到空/脏数据。
- 不校验内容有效性（如邮箱格式、手机号长度）
- 不支持自定义错误提示文案（只能用浏览器默认英文或本地化文案）
- 无法联动其他字段（如“确认密码”需比对“密码”）
- 无法做异步校验（如用户名是否已存在）
required 适合什么场景
它只适合做「第一道轻量拦截」：防止用户手滑跳过必填项，提升基础体验。不是校验，是防呆。
立即学习“前端免费学习笔记（深入）”；
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 纯静态表单，且后端已有完整校验和友好报错
- 内部工具类页面，用户可信、流量可控
- 配合
type="email"、type="number"等增强输入约束（但依然不能替代逻辑校验） - 作为无障碍辅助（告诉屏幕阅读器该字段不可省略）
真正要校验，得靠什么
必须分层处理：前端用 JS 做即时反馈 + 后端用业务逻辑兜底。HTML 层只保留 required 作为辅助。
- 前端用
addEventListener('input')或checkValidity()+setCustomValidity()控制提示 - 正则匹配用
pattern属性（仅对text、search等类型生效，且仍可被绕过） - 复杂规则写在 JS 里，比如日期范围、密码强度、跨字段一致性
- 后端必须独立实现全部校验逻辑，返回结构化错误（如
{ "email": ["格式不正确"] }），前端再映射到对应字段
示例：给邮箱加自定义提示
const emailInput = document.querySelector('input[type="email"]');
emailInput.addEventListener('input', () => {
if (emailInput.value && !/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(emailInput.value)) {
emailInput.setCustomValidity('请输入有效的邮箱地址');
} else {
emailInput.setCustomValidity('');
}
});
容易被忽略的关键点
很多人把 required 当成“已校验”，结果线上出问题才意识到后端没做防护。真实项目里，只要字段有业务含义，就不存在“前端校验够用了”这回事。
另外，required 对 <select> 的空选项、<textarea> 的空白符、type="number" 的空字符串处理不一致，不同浏览器表现也有差异——这些细节在表单混合类型时会突然冒出来。
