HTML必填能替代校验规则吗？其实它俩分工不同

答案很明确：不能。这二者完全是两码事，一个管“有没有”，另一个管“对不对”。

required属性：只是个忠实的“空值检查员”

本质上，required属性是浏览器提供的一道基础防线，专门拦截那些完全没填的字段。一旦某个输入框被标记为必填，而用户又试图留空提交，浏览器就会站出来阻止。

但问题在于，它的判断标准非常单纯：只看“值”是否存在。这就引出了几个常见的误区：

• 一个type="email"的输入框，就算你填了个残缺的foo@，浏览器也认为“有值”，required不会吭声。
• 对于type="number"，如果什么也不填，值其实是空字符串""，这时会触发required；但如果你乱输一个abc，它会被转换成NaN，在required眼里，这居然也算“非空”。
• checkbox必须勾选；radio组则至少得有一个被选中。
• 最后提个醒：给type="hidden"的隐藏域加required是完全没用的，浏览器会直接忽略。

pattern与required：一对好搭档，谁也不能少

如果说required是门卫，那pattern就是质检员。一个负责把人拦在门外，一个负责检查进来的人证件是否合格。它们逻辑独立，必须配合使用。

• 只有pattern，没有required：用户直接把输入框留空，反而能顺利提交。因为没输入，正则校验压根不会执行。
• 只有required，没有pattern：用户倒是填了，但填123还是abc都能过关，哪怕你这个字段明明是用来收集手机号的。
• 正确的写法应该是这样：。这里title属性很贴心，它会在用户输入不符合格式时，作为提示信息显示出来。

别太信任浏览器：移动端与老旧环境的“坑”

把前端校验完全寄托于浏览器特性，有时候会摔跟头。尤其是在一些老旧的移动端浏览器或WebView环境里，required的行为可能相当“任性”。

比如，iOS Safari 12以下版本，或者某些定制的Android WebView，对required的拦截可能不及时，提示样式也可能乱七八糟，甚至干脆静默失效——用户点了提交，页面毫无反应，数据却已经发出去了。

因此，在关键流程（比如注册、支付）中，稳妥的做法是：

• 主动用Ja vaScript调用form.checkValidity()方法，并手动处理校验结果，不要被动等待浏览器弹窗。
• 别用:valid或:invalid这类CSS伪类来做核心的逻辑状态控制，它们的表现可能与实际的校验状态不同步。

最终的底线：服务端校验不可或缺

这一点再怎么强调都不为过：所有前端校验，都仅仅是为了提升用户体验，绝不能当作安全屏障。想绕过它？方法太多了：禁用Ja vaScript、用开发者工具删掉required属性，或者直接用curl这类工具发起POST请求。

所以，后端接收到数据后，第一道工序必须是重复校验：

• 检查字段是否存在、是否为空、格式是否合法（例如用filter_var($email, FILTER_VALIDATE_EMAIL)验证邮箱）。
• 理想情况下，前后端应该使用同一套校验规则（比如同一个正则表达式），避免出现“前端说通过了，后端却打回来”的尴尬局面，导致用户体验断层。
• 对于修改密码、资金转账这类敏感操作，建议增加二次确认或令牌校验机制，不能只依赖表单字段的校验。

说到底，required和pattern的关系，比乍看上去要微妙。不同输入类型对“空值”的定义五花八门，而pattern是否执行，又完全取决于这个“空值”的判断结果。这两层依赖关系，构成了前端表单校验中一个看似简单、实则脆弱的环节。