pattern属性仅在表单提交时触发校验，非实时拦截；需配合type和required使用，正则默认全匹配无需^$，不支持unicode属性类与标志位，安全校验必须由后端完成。
pattern属性为什么没生效
浏览器只在表单提交时触发 pattern 校验，输入过程中不报错、不拦截、不提示。很多人以为加了 pattern 就能实时阻止非法输入，其实它只是“提交守门员”，不是“键盘过滤器”。
- 必须配合
type="text"（或email、url等原生类型）和required才容易观察到效果；否则空值提交可能绕过校验 -
pattern的正则默认是“全匹配”，不需要写^和$—— 浏览器自动加上了，写了反而容易出错 - 中文、emoji、全角字符容易被忽略：比如想限制“纯数字”，
pattern="\d+"无法阻止用户粘贴全角数字（如「１２３」），因为\d只匹配 ASCII 数字
手机号、邮箱这类常见场景怎么写pattern
别直接抄网上泛用正则，得看你要拦什么、放什么。浏览器的 pattern 不支持标志位（如 i、u），也不支持 Unicode 属性类（如 \p{Emoji}），能力很基础。
- 中国大陆手机号（11位、1开头）：
pattern="1[3-9]\d{9}"—— 注意不要写^1[3-9]\d{9}$，会多一层隐式匹配导致失败 - 简单邮箱（不追求 RFC 合规）：
pattern="[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$"，但注意：小写字母限定会让大写邮箱提交失败，如需忽略大小写，只能靠 JS 补充处理 - 密码至少8位含数字和字母：
pattern="(?=.*\d)(?=.*[a-zA-Z]).{8,}"—— 虽然部分浏览器支持前瞻断言，但 Safari 旧版本不认，生产环境慎用
pattern和JavaScript验证怎么配合才不重复踩坑
pattern 是 HTML 原生层的轻量约束，JS 是执行层的精准控制。两者不是替代关系，而是分层协作：HTML 拦明显错误，JS 处理复杂逻辑和用户体验。
- 不要只靠
pattern做安全校验——它完全可被禁用或绕过，后端必须重新验证 - JS 中监听
input事件做实时提示时，别用setCustomValidity()反复覆盖，容易和pattern冲突；建议统一用reportValidity()触发原生气泡 - 移动端软键盘适配：某些安卓浏览器对
pattern响应迟钝，可额外设inputmode="numeric"或inputmode="email"来唤起对应键盘，但这是提示，不是限制
Chrome开发者工具里怎么看pattern是否被识别
打开 DevTools → Elements 面板，找到 input 元素，展开看 computed 样式下方有没有 valid 或 invalid 伪类状态。更直接的是在 Console 里运行：
立即学习“前端免费学习笔记（深入）”；
document.querySelector('input').checkValidity()
返回 false 且有 validationMessage，说明 pattern 已生效并触发了校验逻辑。
- 如果
checkValidity()总是true，先确认该input是否在form内、是否设置了name属性（部分老版本需要） - 如果正则本身有语法错误（比如未闭合括号），Chrome 不报错，但
pattern会被静默忽略——此时checkValidity()仍返回true，非常难排查
