HTML5邮箱pattern正则必须将连字符-置于字符类首或尾以避免解析错误，禁用^$锚点（浏览器自动隐式添加），需转义点号.，配合type="email"和required使用，并辅以title提示；但仅作前端初步校验，不可替代后端验证。
仅靠 pattern 属性写正则校验邮箱，容易因字符类写法错误直接导致浏览器解析失败（比如报 Invalid character in character class），而且即使语法通过，也可能误拒合法邮箱（如 user@sub-domain.com）或放行明显异常格式（如 a@b.c）。必须兼顾 HTML 的 pattern 解析规则和域名实际规范。
pattern 中连字符 - 必须放在字符类开头或结尾
这是最常踩的坑。在 [a-z0-9._%-] 这类写法中，%- 被浏览器当作“从 % 到 - 的 Unicode 范围”解析，而该范围非法，直接报错。正确做法只有两种：
-
[a-zA-Z0-9._%+-]（-放末尾，无需转义） -
[-a-zA-Z0-9._%+]（-放开头，也安全）
别用 [a-z%-] 或 [a-z%\-] —— 后者在 HTML 属性里反而可能被双转义出问题。
不要手动加 ^ 和 $ 锚点
pattern 属性本身就会自动对整个输入值做全匹配（隐式添加 ^ 和 $）。显式写出会导致部分浏览器解析歧义，尤其当正则里还有其他特殊字符时。
- ✅ 正确：
pattern="[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}" - ❌ 危险：
pattern="^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$"
注意：末尾的 \. 中的反斜杠是必须的，因为点号在正则里是元字符，不转义就变成“任意字符”了。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
type="email" 和 pattern 要配合使用，不能只靠一个
type="email" 提供基础防护（比如强制含 @、不允许空格、移动端唤起邮箱键盘），pattern 是增强层，用来收紧顶级域长度、禁止单字母 TLD 等。两者叠加才合理：
- 必须同时加
required，否则空值会绕过pattern校验 - 推荐加上
title属性，失败时部分浏览器会显示该提示，比默认文案更友好 - 示例完整写法：
这个正则仍不能替代后端验证
它只解决“看起来像邮箱”的问题，对以下情况完全无能为力：
- 用户粘贴了多个邮箱用逗号分隔：
a@b.com,c@d.com—— 浏览器认为合法 - 域名拼写错误但格式合规：
user@gmil.com - 企业邮箱常见但服务端不支持的格式：
user+tag@domain.com - 国际化域名（含中文）需 Punycode 编码，前端 pattern 无法处理
真正关键的校验点永远在服务端：用 filter_var($email, FILTER_VALIDATE_EMAIL)（PHP）、validator.isEmail()（JS）或 SMTP 预检，而不是纠结前端正则能不能覆盖 RFC 5322 全集。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
