pattern属性仅在表单提交或checkValidity()时触发完全匹配校验，不实时监听、不支持标志位、需手动处理转义和大小写，错误提示依赖title，兼容性有限且必须服务端兜底。
input 的 pattern 属性能做什么、不能做什么
pattern 是 HTML5 原生支持的正则校验方式，但它只在表单提交时触发（或调用 checkValidity() 时），**不会实时监听输入**。它只对 和 有效，且正则写法有隐含限制：浏览器会自动在你写的正则前后加上 ^ 和 $，所以 pattern="\d+" 实际等价于 /^d+$/ —— 想匹配“至少一位数字”可以，但想匹配“包含数字即可”就不行，得换思路。
常见错误是直接把 JavaScript 正则粘贴进去，比如写 pattern="/^[a-z]+@example.com$/"，这会导致校验失效，因为斜杠和转义在 HTML 属性里不被识别；正确写法是去掉斜杠，双反斜杠写成四个：pattern="^[a-z]+@example\.com$"。
- 只校验值是否**完全匹配**该正则，不支持
g、i等标志（大小写不敏感需手动写[A-Za-z]） - 不提供错误提示文案，靠
title属性补充，如title="请输入邮箱格式" - 提交时若不满足，会阻止表单提交，并聚焦到该字段，但 UI 提示非常简陋（仅浏览器默认气泡）
用 addEventListener('input') 做实时反馈更可控
如果需要输入过程中就高亮错误、动态启禁提交按钮、或显示自定义提示，必须用 JavaScript 监听 input 事件。注意别用 change，它只在失焦时触发，体验差。
关键点在于：正则测试要用 RegExp.prototype.test()，而不是 .match() 或字符串方法，因为前者返回布尔值，语义清晰；同时要避免重复绑定，尤其在 SPA 中反复渲染表单时。
- 对密码强度校验，可分步写多个正则：
/[a-z]/、/[A-Z]/、/\d/、/[^a-zA-Z0-9]/，逐个test(input.value) - 中文手机号校验建议用
^1[3-9]\d{9}$，别依赖运营商号段库，前端只需基础格式拦截 - 实时校验后，用
element.setCustomValidity()配合reportValidity()可统一控制原生验证行为
提交前用 form.checkValidity() + 自定义逻辑兜底
用户可能绕过前端校验（比如禁用 JS、改 DOM），所以服务端校验不可省；但前端提交控制仍有必要——防止无效请求堆积、提升响应感知。不要只依赖 onsubmit="return false" 这种粗暴方式。
推荐在 submit 事件中先调用 form.checkValidity()，它会触发所有 pattern 和必填校验，返回 true 或 false；再叠加业务逻辑，比如“两次输入密码是否一致”、“同意协议复选框是否勾选”。
- 若校验失败，
event.preventDefault()必须显式调用，否则表单仍会提交（即使checkValidity()返回false） - 禁用提交按钮时，记得同时设
aria-disabled="true"，兼顾可访问性 - 避免在提交处理中嵌套异步操作（如发请求）后才校验，应先同步完成所有校验，再发请求
容易被忽略的兼容性与体验细节
pattern 在 IE 完全不支持，Android 4.4 以下 WebView 表现不稳定；而 input 事件在 iOS Safari 旧版本中对粘贴（paste）不触发，需额外监听 paste 并 setTimeout 延迟校验。
移动端软键盘唤起后，若校验失败并聚焦，可能遮挡输入框——此时需手动滚动，用 element.scrollIntoView({ behavior: 'smooth', block: 'nearest' })。
-
type="email"或type="url"本身带基础校验，但不如pattern精确，且无法禁用（比如允许本地域名localhost就得靠pattern） - 正则中的 Unicode 字符（如中文、emoji）需确保页面编码为 UTF-8，且正则写法兼容：用
\u4e00-\u9fa5而非[u4e00-u9fa5]（后者在某些老环境解析异常） - 表单重置（
form.reset()）不会清除通过setCustomValidity()设置的错误状态，需手动重置：input.setCustomValidity('')
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
