HTML 的 pattern 属性提供零 JS 的轻量正则验证，但仅提交时触发、不支持 ^$ 锚点、需纯字符串格式且隐式全匹配；错误提示靠 title，失败无反馈，移动端兼容差；复杂场景须用 JavaScript 的 test() 方法并注意边界处理。
HTML 本身不执行正则匹配逻辑，pattern 属性只是把正则交给浏览器验证引擎去跑 —— 它只在提交时触发，且不支持所有 JS 正则语法（比如不支持 ^ 和 $ 的语义化锚点，因为浏览器会自动加）。
用 pattern 属性做基础正则验证
这是最轻量、零 JS 的方式，适合邮箱、手机号、邮编等格式固定场景。关键点是：pattern 值必须是**不带斜杠的纯正则字符串**，且浏览器默认把它当作“全匹配”处理（相当于隐式包裹了 ^...$）。
-
pattern="[0-9]{6}"表示必须且仅能输入 6 位数字，输 5 位或 7 位都会失败 -
pattern="1[3-9]\d{9}"可用于中国大陆手机号，但注意：它不会阻止用户粘贴空格或括号，type="tel"更合适 - 错误提示靠
title属性：如title="请输入6位数字"，用户 hover 或提交失败时显示 - 不要写
pattern="/^[0-9]{6}$/"—— 斜杠和修饰符（如g、i）会被当作文本字面量，直接导致验证失效
pattern 验证失败时表单不提交，但没反馈
原生 pattern 验证只阻断提交，不主动高亮或提示。用户可能只看到空白弹窗或无反应，体验差。常见问题：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 用户改完内容后再次点击提交，仍报错 —— 因为
input元素的validity.valid状态未重置，需手动调用reportValidity() -
setCustomValidity("")必须在每次输入后清空，否则旧错误会残留；建议绑定input或blur事件来实时清理 - 移动端 Safari 对
pattern支持较弱，比如对中文字符集[\u4e00-\u9fa5]可能完全忽略
用 JavaScript + test() 做可控验证
当需要实时反馈、组合校验（如两次密码一致）、或兼容老浏览器时，必须用 JS。核心是 RegExp.prototype.test()，它返回布尔值，不抛错，适合条件判断。
立即学习“前端免费学习笔记（深入）”；
- 定义正则要写成字面量形式：
const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;，别用字符串构造（new RegExp("...")），避免双重转义 - 手机号验证别只信
1[3-9]\d{9}—— 它漏掉 170/171/166 等虚拟运营商号段，更稳妥的是用/^1[3-9]\d{9}$|^1[3-9]\d{4}\d{5}$/（后者兼容带分隔符粘贴） - 中文姓名验证慎用
[\u4e00-\u9fa5]—— 它不含「·」（间隔号）、英文名、港澳台常用异体字，真实业务中常放宽为[\u4e00-\u9fa5a-zA-Z·\s]并限制长度 - 调用
test()前务必先.trim()，否则前后空格会导致邮箱、用户名等验证意外失败
容易被忽略的边界情况
正则验证最坑的地方不在语法，而在数据来源和用户行为：
- 用户从微信/钉钉粘贴内容时，常带不可见 Unicode 字符（如
\u200b零宽空格），trim()清不掉，得用.replace(/[\u200b\u200c\u200d\uFEFF]/g, '') -
type="email"和pattern冲突：如果同时设type="email"和pattern，Chrome 会优先走 type 验证，pattern 可能被跳过 - 密码强度正则如
/(?=.*[a-z])(?=.*[A-Z])(?=.*\d)/在 iOS 键盘切换大小写时可能误判，建议改用分步检查而非单条正则 - 服务端永远要重复校验 —— 前端正则只是体验优化，不能替代后端防护
