required仅触发空值校验，不校验内容合法性；对input取value.trim()===""，对select检查selectedindex===0且首option无值或为空字符串；它不触发type内置格式校验，需提交或调用checkvalidity()才执行。
HTML 表单中 required 属性到底触发什么校验
required 是原生 HTML 表单最基础的必填控制，但它只做「空值校验」，不关心内容是否合法。比如 <input type="email" required>，用户填了 "abc" 也能通过提交——因为非空，尽管格式错误。
常见错误现象：加了 required 却没拦住非法邮箱、手机号或空格字符串；用户提交后才在 JS 中发现数据不对，体验割裂。
-
required判定“空”的逻辑是：对<input>类型，取value.trim() === ""；对<select></select>，检查selectedIndex === 0且首个<option></option>没有value或值为空字符串 - 它不触发
type="email"、type="url"等内置格式校验，除非表单真正提交（或调用checkValidity()） - 移动端软键盘可能不显示“完成”按钮，导致用户误以为可跳过——这不是 bug，是浏览器对
required的宽松交互策略
什么时候该用 pattern 而不是只靠 required
当“必填”之外还要约束格式时，pattern 是最轻量的补充方案。它和 required 协同工作：先过空值检查，再跑正则匹配。
使用场景：手机号（11位数字）、身份证号（18位含X）、自定义用户名（字母开头+数字下划线）等无法用原生 type 覆盖的规则。
-
pattern的正则默认是“全匹配”，即自动加上^...$，不用手动写首尾锚点 - 错误提示文案由浏览器控制，不可直接定制；如需友好提示，必须监听
invalid事件并调用setCustomValidity() - 注意转义：正则中的反斜杠在 HTML 属性里要写成双反斜杠，例如
pattern="[0-9]{11}"正确，而pattern="\d{11}"会失效（\d不被 HTML 属性解析）
checkValidity() 和 reportValidity() 的实际分工
手动触发校验时，这两个 API 常被混用，但行为差异直接影响用户体验。
-
checkValidity()只返回布尔值，不弹提示、不聚焦元素，适合静默校验（比如防重复提交前快速判断） -
reportValidity()会触发完整校验流程：高亮错误字段、显示气泡提示、聚焦第一个违规项——等价于用户点了提交按钮但表单不满足条件 - 如果用 JS 动态修改了
value，记得在调用前先触发input或change事件，否则浏览器内部状态可能未更新，导致reportValidity()结果不准
服务端永远要重验，前端校验只是体验层
所有前端校验（required、pattern、JS checkValidity()）都可被绕过：禁用 JS、改 DOM、抓包重发……所以它们唯一作用是减少无效请求、提升用户操作反馈速度。
容易被忽略的点：
- 后端收到数据后，必须独立执行完整校验逻辑，不能信任任何前端传来的
required或pattern结果 - 前后端正则不一致是高频坑：比如前端用
pattern="[a-z0-9_]{3,16}"，后端却允许大写字母或连字符，会导致“前端能过、后端报错” - 国际化场景下，某些校验（如手机号区号、身份证编码规则）必须由后端根据用户地区动态判断，前端无法可靠覆盖
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
