HTML必填不能完全替代校验规则。

HTML 的 `required` 属性仅是防手滑的轻量级空值拦截工具，既不验证内容合法性（如邮箱格式、数字有效性），也无法抵御绕过（禁用JS、删属性、直接POST）、不支持自定义提示、联动校验或异步检查，更不能替代真正的业务校验逻辑；它只应在后端已有完备防护、用户可信或纯静态场景中作为辅助体验层存在，而可靠校验必须依赖前端JavaScript的即时反馈与后端独立、健壮的业务逻辑双重保障——忽视这一分层原则，极易导致线上数据污染和用户体验崩塌。

required 属性不能替代校验规则，它只是最基础的客户端空值拦截，绕过简单、无语义、不防提交。

为什么 required 不能当校验用

它只检查控件是否有用户输入（对 <input> 类型而言），不关心内容是否合法。比如邮箱字段加了 required，用户填 abc 也能通过；数字字段填 123abc 同样能提交——浏览器根本不校验格式或类型。

更关键的是，required 完全依赖 HTML 表单原生行为，一旦用户禁用 JS、手动删掉属性、或用 POST 工具直接发请求，后端照样收到空/脏数据。

• 不校验内容有效性（如邮箱格式、手机号长度）
• 不支持自定义错误提示文案（只能用浏览器默认英文或本地化文案）
• 无法联动其他字段（如“确认密码”需比对“密码”）
• 无法做异步校验（如用户名是否已存在）

required 适合什么场景

它只适合做「第一道轻量拦截」：防止用户手滑跳过必填项，提升基础体验。不是校验，是防呆。

• 纯静态表单，且后端已有完整校验和友好报错
• 内部工具类页面，用户可信、流量可控
• 配合 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" 的空字符串处理不一致，不同浏览器表现也有差异——这些细节在表单混合类型时会突然冒出来。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《HTML必填不能完全替代校验规则。》文章吧，也可关注golang学习网公众号了解相关技术文章。