required仅校验是否为空，不校验格式；type和pattern负责格式校验但各有局限：required在submit时触发，type="number"输入空格仍通过，type="date"非法值不触发required；pattern仅对部分type生效且自动加^$，不支持正则flag；min/max/step在number和date中行为不同；setcustomvalidity需手动清空错误；原生校验不监听input，实时反馈须js调用checkvalidity()。
required 只管“有没有”，不管“对不对”；真正做格式校验的是 type 和 pattern，但它们各自有硬限制，且不自动协同。
required 属性为什么有时没反应？
它只在 form 提交时触发，且仅判断是否为空值——不是空格、不是 undefined、不是未选状态。常见失效场景：
- 表单没用
<form></form>包裹，浏览器不识别为可验证控件 - 提交按钮是
<button type="button"></button>或 JS 调用form.submit()，跳过了原生校验流程 -
type="number"输入了"123 "（尾部空格），required会接受；但输入"abc"会被拒绝（number 类型本身做了基础解析） -
type="date"已选了一个非法值如"9999-99-99"，required不报错——它只在完全未选时设validity.valueMissing = true
type="email" 和 pattern 哪个才是真校验？
type="email" 是语义提示 + 极宽松格式锁：只要含一个 @ 和至少一个点号（如 a@b.c、user@localhost）就过。真正可控的只有 pattern，但它有三重约束：
- 只对
type="text"、"email"、"url"、"password"等生效，对type="number"完全无效 - 浏览器自动给正则加
^和$，你写pattern="^[a-z]{3,}$"会直接报Invalid regular expression - 不支持
i、m等 flag，大小写敏感要靠[a-zA-Z]，中文得显式写[\u4e00-\u9fa5]
示例：限制 6–12 位字母数字，正确写法是 pattern="[a-zA-Z0-9]{6,12}"；想禁止开头为数字，得用 pattern="(?!\d)[a-zA-Z0-9]{6,12}"（注意 JS 字符串中需双反斜杠："(?!\d)[a-zA-Z0-9]{6,12}"）
min/max/step 在 number 和 date 中行为完全不同
这些属性看着一样，实际校验逻辑和时机差异极大：
-
type="number"：输入过程就拦截（如min="10"，用户无法手动输入 9）；step="0.1"不等于“允许一位小数”，填1.01仍失败；粘贴内容也会被step拒绝 -
type="date"：仅在submit或调用checkValidity()时校验；step完全无效（HTML5 规范明确不支持）；min="2023-01-01"要求值是完整 ISO 格式，"2023-1-1"或"2023/01/01"都解析失败 →value为空 →required才可能触发
setCustomValidity 怎么用才不翻车？
这是唯一能覆盖原生错误提示的接口，但必须手动清空，否则后续校验永远卡在旧错误上：
- 调用
input.setCustomValidity("错误信息")后，该字段始终为 invalid，直到你显式调用input.setCustomValidity("") - 推荐在
input或blur事件里做实时校验，每次先清空再设新错误：input.setCustomValidity(""); if (!isValid) input.setCustomValidity("手机号格式错误"); - 不要依赖
validity.valid判断整体状态——它受setCustomValidity、required、pattern等多个因素影响，更可靠的是查具体字段如validity.valueMissing、validity.patternMismatch
最易忽略的一点：所有原生校验都只响应 submit 事件，不监听 input；而用户真正需要的实时反馈，必须靠 JS 主动调用 checkValidity() 并处理 validity 对象——这一步，没人替你做。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
