required仅作基础空值拦截,不校验内容合法性、不防绕过、无自定义提示、不支持联动与异步校验,仅适用于防手滑的轻量辅助场景。

required 属性不能替代校验规则,它只是最基础的客户端空值拦截,绕过简单、无语义、不防提交。
为什么 required 不能当校验用
它只检查控件是否有用户输入(对 <input> 类型而言),不关心内容是否合法。比如邮箱字段加了 required,用户填 abc 也能通过;数字字段填 123abc 同样能提交——浏览器根本不校验格式或类型。
更关键的是,required 完全依赖 HTML 表单原生行为,一旦用户禁用 JS、手动删掉属性、或用 POST 工具直接发请求,后端照样收到空/脏数据。
- 不校验内容有效性(如邮箱格式、手机号长度)
- 不支持自定义错误提示文案(只能用浏览器默认英文或本地化文案)
- 无法联动其他字段(如“确认密码”需比对“密码”)
- 无法做异步校验(如用户名是否已存在)
required 适合什么场景
它只适合做「第一道轻量拦截」:防止用户手滑跳过必填项,提升基础体验。不是校验,是防呆。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML,替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度,HTML 能同时承载排版、表格、SVG 等。
- 纯静态表单,且后端已有完整校验和友好报错
- 内部工具类页面,用户可信、流量可控
- 配合
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></select> 的空选项、<textarea></textarea> 的空白符、type="number" 的空字符串处理不一致,不同浏览器表现也有差异——这些细节在表单混合类型时会突然冒出来。
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!










