pattern属性仅作前端格式提示，不保证数据合规，真正合规须依赖后端白名单校验与前端协同；其正则不加/^$/、需配title提示、移动端支持弱，且不可替代inputmode等输入体验优化手段。
pattern 属性只做前端提示，不保证数据合规
pattern 是 的 HTML5 原生属性，用正则表达式约束用户输入格式。但它仅在表单提交前触发浏览器原生校验，**不拦截非法值、不阻止提交（除非同时加 required 且验证失败）、不参与后端逻辑**。常见误解是以为加了 pattern 就“合规”了，实际它连字符串是否真正匹配都可能因浏览器实现差异而表现不一致。
实操建议：
-
pattern的正则**不带/^...$/边界符**，浏览器自动按全字符串匹配处理；写成pattern="^[a-z]{3}$"反而可能失效 - 必须配合
title属性提供友好提示，否则 Chrome 等只显示“请与所要求的格式匹配”这种无意义文案 - 移动端 Safari 对
pattern支持较弱，部分机型直接忽略；不能依赖它控制键盘类型（如数字键盘），应改用inputmode或type="number"
真正合规要靠后端白名单校验 + 前端辅助
前端任何校验（包括 pattern、JavaScript 正则、甚至 WebAssembly 验证）都可被绕过。所谓“HTML5 合规取法”，本质是前后端协同：前端用 pattern 降低误输率，后端用确定性规则（如白名单字符集、严格正则、长度限制）做最终裁定。
例如邮箱字段：
立即学习“前端免费学习笔记（深入）”；
这只能拦住明显乱输（如 @@@），但无法排除 test@localhost 或超长编码邮箱。后端必须用更严规则，比如：
- 拒绝
@后无点号或点号后少于 2 字符的域名 - 对本地部分（@前）只允许 ASCII 字母、数字、
._%+-，且不以.开头/结尾、不连续出现. - 总长度不超过 254 字符（RFC 5321）
pattern 和 JavaScript 校验别混用同一正则
HTML5 pattern 和 JS RegExp 对正则语法支持不同。比如 \p{L}（Unicode 字母）在 pattern 中无效，但 JS 可用；pattern 不支持 g 或 m 标志，而 JS 支持。
常见错误：
- 把 JS 里写的
/^[a-z\u4e00-\u9fa5]+$/直接塞进pattern——\u4e00-\u9fa5在 HTML 属性中不解析为 Unicode，会变成字面量\u4e00-\u9fa5，导致永远不匹配 - 用
pattern="(?i)abc"期望忽略大小写 —— 多数浏览器不支持内联标志，应改用pattern="[aA][bB][cC]"或靠后端统一转小写
安全做法：前端 pattern 仅用于简单格式引导（如手机号前缀、邮编位数），复杂逻辑全交由后端；若需 JS 动态校验，单独写兼容性更好的正则，不要复用 pattern 值。
inputmode 比 pattern 更影响实际输入体验
用户能不能方便地输入合规内容，往往取决于键盘类型，而非 pattern 提示。比如想限制纯数字，pattern="[0-9]+" 不如 inputmode="numeric" type="text" 或 type="tel" 有效——前者只校验，后者直接唤起数字键盘，从源头减少字母误触。
关键区别：
-
type="number"会强制转换值为数字（含去除非数字字符），但提交时可能丢失前导零（如电话区号021变成21），此时应选type="text" inputmode="numeric" -
inputmode="decimal"在 iOS 上唤出带小数点的键盘，比pattern="\d+\.?\d*"更实用 -
pattern对contenteditable或非元素无效，这类场景必须用 JS 监听input事件实时过滤
真正难的不是写对 pattern，而是意识到它只是表层提示；所有“合规”判断必须落在后端不可绕过的逻辑里。前端越努力模拟后端规则，越容易因环境差异埋下漏洞。
