required、type="email"、pattern 是现代表单校验起点，正确使用可覆盖80%基础校验；它们触发浏览器原生约束验证流程，支持无障碍、移动端键盘优化及气泡提示，配合constraint validation api可扩展自定义校验。
required、type="email"、pattern 这些属性不是“可选装饰”，而是现代表单校验的起点——用对了，80% 的基础校验不用写 JS。
为什么直接写 required 比监听 submit 更可靠
很多人习惯在 JS 里监听 submit 事件再手动判断字段是否为空，但这样会绕过浏览器原生的约束检查机制，导致两个问题：
一是用户没触发 submit（比如按回车）时，blur 或 input 事件又没监听全，错误就漏过了；二是无法触发 reportValidity() 和内置气泡提示，无障碍支持直接打折。
用 required 后，浏览器会在任何提交动作（点击按钮、回车、JS 调用 form.submit()）前自动校验，并阻止提交，同时聚焦到第一个违规字段。
-
required是语义级声明，不是样式或逻辑开关，它参与 Constraint Validation API 的完整流程 - 搭配
aria-invalid="false"和aria-describedby可无缝对接读屏软件 - 移动端软键盘会根据
type自动切换（如type="email"弹出 @ 键），这是 JS 监听做不到的
pattern 的正则必须是全匹配，否则形同虚设
pattern 实际上等价于 ^regex$，浏览器会强制从头到尾匹配。常见错误是直接抄 JS 里用的正则，比如邮箱写成 /\S+@\S+\.\S+/，但放在 pattern 里得去掉斜杠和修饰符，写成 pattern="\S+@\S+\.\S+" —— 这样依然错，因为缺少 ^ 和 $，实际匹配的是子串。正确写法是：
<input type="text" pattern="[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}" title="请输入有效邮箱">
- 所有特殊字符在 HTML 属性值中需转义，但正则内部不用额外转义斜杠（因为没用 / 包裹）
-
title不是可选项：它是验证失败时气泡里显示的文案，不加的话提示就是浏览器默认的英文（如 “Please match the requested format”） - 移动端 Safari 对
pattern支持较弱，遇到复杂正则建议降级为 JS 校验 +setCustomValidity()
当原生校验不够用时，用 setCustomValidity() 接管错误状态
原生属性解决不了的场景：两次密码不一致、用户名已被注册、实时字数统计超限、依赖其他字段联动校验……这时候不要删掉原生属性，而是用 Constraint Validation API 增强它。
- 调用
input.setCustomValidity("错误信息")会覆盖所有原生校验结果，空字符串表示“通过” - 必须在每次输入后重置并重新计算，否则错误状态会残留（比如输错密码后改对了，但没调用
setCustomValidity("")，字段仍被标记为无效） - 配合
checkValidity()和reportValidity()可实现手动触发校验，适合在按钮点击或离开页面前做兜底检查
别忽略 novalidate 的真实用途
很多人以为 novalidate 就是“关掉所有校验”，其实它只禁用原生约束检查，但不阻止 submit 事件、不取消 setCustomValidity()、也不影响你手写的 JS 校验逻辑。它的典型使用场景是：
- 表单含动态字段（如可增删的地址列表），部分字段初始为空但合法，此时用
novalidate避免加载即报错 - 需要完全自定义 UI 提示（比如用 Tooltip 替代气泡），但又想保留
validity对象供 JS 读取状态 - 服务端渲染的表单，校验规则由后端注入，前端统一用 JS 解析执行，原生属性仅作 fallback
真正容易被忽略的是：加了 novalidate 后，form.checkValidity() 依然返回 true/false，因为这个方法只检查 validity 状态，和是否启用原生校验无关。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
