required仅拦截空提交，无法识别空格、非法值等脏数据，且前端验证可被轻易绕过，真正可靠的验证必须由后端完成。
required 属性只能拦截空提交，拦不住脏数据
required 只检查字段是否为空字符串、null 或未聚焦过（部分浏览器行为），对以下情况完全无感：
用户填了空格、制表符、换行符；填了 " "；填了 "0" 但业务要求必须是正整数；填了邮箱格式但域名不存在。它不触发任何类型转换或语义校验，纯属“表面没空”就放行。
绕过 required 几乎不需要技术手段
前端验证全在用户手里，禁用 JS、手动修改 DOM、用 curl/postman 直发请求，都能跳过 required。常见错误是开发者看到表单提交失败就以为“用户被拦住了”，其实只是浏览器默认弹了个提示框——这个提示可被关闭、屏蔽、忽略，甚至被自动化脚本跳过。
实际场景中：
• 浏览器开发者工具里删掉 required 属性，秒过
• 复制表单 HTML 到本地文件，去掉 required 后直接提交
• 使用 fetch 绕过表单 submit 事件，直调接口
required + pattern 仍不等于可靠验证
pattern 属性依赖正则，但只在输入失去焦点或提交时触发，且不校验输入过程中的中间状态。更关键的是：
• 正则写错很常见（比如 pattern="[a-z]+" 允许空字符串，得加 ^$ 边界）
• 不同浏览器对 pattern 的支持程度不一（Safari 对某些 Unicode 处理异常）
• 即使正则正确，也无法替代服务端对长度、SQL 注入、XSS、业务规则（如“不能与用户名相同”）的判断
• setCustomValidity() 手动设错提示，若没在每次输入后重置，会导致旧错误一直卡住提交
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
真正该做的验证分层策略
把验证当成本能反应，而不是“加个属性就完事”：
• 前端：用 required + type="email" + minlength 做快速反馈，配合 JS 实时监听 input 事件做轻量过滤（比如自动 trim 空格、阻止非数字输入）
• 中间层（如 API 网关）：校验基础结构（Content-Type、JSON 格式、必填字段是否存在）
• 后端：对每个字段做完整解析、类型断言、范围检查、唯一性查库、权限校验——这才是唯一可信的防线
• 关键操作（如支付、删账号）必须二次确认 + token 防重放，不能只信前端传来的 “isConfirmed: true”
立即学习“前端免费学习笔记（深入）”；
最容易被忽略的点是：很多人把 required 当成“已验证”的信号，在后端直接 data.email 就入库，结果数据库收到空字符串或超长字符串，引发约束错误或截断。验证不是加属性，是建立信任链——而链的终点永远在服务端。
