required 不能替代 pattern，二者功能正交：required 仅校验非空，pattern 负责格式合法性；需配合使用，且后端必须重复校验。

不能替代。required 只管“有没有填”，不管“填得对不对”。

required 属性只做空值拦截，不校验内容合法性

它本质是浏览器原生的提交拦截机制：当 input、select 或 textarea 带有 required，且其 value 为空字符串（""）或未选中时，表单 submit 会被阻止。

• type="email" 填了 foo@ 也算“有值”，required 不报错
• type="number" 空着时 value 是 ""，触发 required；但填了 abc 会自动转成 NaN，此时 required 仍通过（因非空）
• type="checkbox" 必须勾选才满足；type="radio" 同组至少一个被选中
• type="hidden" 加 required 完全无效，浏览器直接忽略

pattern 和 required 要配合用，不能互相代替

pattern 负责格式匹配，required 负责非空判断——两者逻辑正交，缺一不可。

• 只写 pattern 不写 required：用户留空也能提交（正则不生效，因无输入）
• 只写 required 不写 pattern：用户填 123 或 abc 都能过，哪怕字段是手机号
• 正确写法：<input type="tel" required pattern="^1[3-9]\d{9}$" title="请输入11位中国大陆手机号">
• title 属性在不匹配 pattern 时显示提示，但不会影响校验逻辑

移动端和老旧 WebView 的 required 行为不稳定

iOS Safari 12 以下、部分 Android WebView 对 required 的拦截时机或提示样式支持不一致，甚至完全静默失效。

Html2md

使用 Readability + Turndown 将 HTML 页面转换为干净的、Agent 友好的 Markdown。去除导航栏、广告、页脚、Cookie 横幅、社交按钮等干扰元素。支持 URL...

下载

立即学习“前端免费学习笔记（深入）”；

• 用户点击提交后无任何反馈，表单直接发往服务端
• 某些场景下 checkValidity() 返回 true，但实际没校验
• 关键流程（如注册、支付）必须用 JavaScript 主动调用 form.checkValidity() 并手动处理结果
• 不要依赖 :valid/:invalid CSS 伪类做核心状态控制，它们可能不同步

服务端必须重复校验，前端验证只是体验层

绕过前端只需禁用 JS、删掉 required 属性、或用 curl 直接 POST，所有前端限制瞬间失效。

• 后端收到数据后，第一件事不是业务逻辑，而是检查字段是否存在、是否为空、是否符合格式（如用 filter_var($email, FILTER_VALIDATE_EMAIL) 或正则）
• 前后端应共用同一套正则规则，避免“前端说对、后端说错”的体验断裂
• 敏感操作（如密码修改、资金转账）建议增加二次确认或 token 校验，不只依赖表单字段校验

真正容易被忽略的是：required 的“空”定义因 type 而异，而 pattern 的执行又依赖于这个“空”是否被跨过——这两层耦合关系，比表面看起来更脆弱。