17370845950

required 属性仅在表单提交或调用 checkValidity() 时触发验证，失焦（blur）不自动校验；pattern 值为纯字符串，不可带斜杠和 flag；type="email"/"url" 验证宽松，仅作基础格式筛查；validity 对象需细查具体属性定位错误原因。

required 属性是否触发验证取决于表单提交行为

HTML5 的 required 不是“实时监听”，它只在表单提交（submit 事件）或调用 checkValidity() 时才真正参与验证逻辑。用户输入空值后直接点提交，浏览器会自动聚焦并提示“请填写此字段”；但若只是聚焦离开（blur），默认不报错。

常见误区：给 input 加了 required 却没看到即时反馈，其实是预期错了——这不是 bug，是规范行为。

• 必须通过 form.submit() 或用户点击 才触发内置校验
• input.addEventListener('blur', () => input.checkValidity()) 可手动触发，但不会自动显示默认气泡提示
• 想实现“失焦即验”，得配合 setCustomValidity() + 手动控制 reportValidity()

pattern 属性的正则写法必须不含首尾斜杠且不支持 flags

pattern 值是纯字符串，不是 JS 正则字面量。写成 pattern="/^\d{6}$/" 会失效——浏览器把它当字面文本去匹配，根本不会解析为正则。

正确写法是去掉斜杠，也不支持 i、g 等 flag：

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

注意：pattern 默认是“全字符串匹配”，等价于 ^...$，无需手动加锚点（加了也没错，但冗余）。

• 不支持 \b、\s 等部分转义（取决于浏览器对 Unicode 的支持程度，建议用 [0-9] 替代 \d 提高兼容性）
• 中文字符需用 Unicode 范围，如 [\u4e00-\u9fa5]{2,10}，但某些旧版 Safari 可能不识别
• 错误示例：pattern="/^[a-z]+$/i" → 浏览器当作字面字符串 "/^[a-z]+$/i" 匹配，永远失败

type="email" 和 type="url" 的验证宽松得超出预期

type="email" 只要求含一个 @ 和至少一个点（.），user@domain 都能过；type="url" 甚至接受 http://x 这种明显非法格式。它们不是 RFC 校验器，只是基础格式筛子。

这意味着：不能靠它们防恶意输入，仅适合拦截明显乱输（比如空格、无 @ 的字符串）。

• type="email" 允许 a@b.c.d.e、test@localhost（无 TLD）
• type="url" 不校验协议是否存在，ftp://foo、xxx://bar 都算合法
• 真实项目中，服务端仍必须做完整解析（如用 URL 构造函数或正则二次校验）

validity 对象的布尔属性容易被误读

input.validity.valid 是最终结果，但它的 false 并不告诉你具体哪条规则失败。要定位原因，得查更细的属性，比如 valueMissing、typeMismatch、patternMismatch。

典型误用：if (!input.validity.valid) { alert('错了') } —— 这样无法区分是没填、格式错、还是正则不匹配。

• 推荐组合判断：input.validity.valueMissing（对应 required）、input.validity.patternMismatch（对应 pattern）
• input.validationMessage 会返回浏览器默认提示文本，可直接用于 UI 展示，但内容不可控（中英文随系统 locale 变）
• 调用 input.setCustomValidity('手机号格式不对') 后，validity.customError 为 true，且 validity.valid 自动变 false

浏览器内置验证看起来简单，但每个属性背后都有明确的触发时机和边界条件。最常被忽略的是：它只管“格式有没有明显破绽”，不管“语义对不对”——手机号 13800138000 符合 pattern="\d{11}"，但未必真实存在。