uni-app邮箱校验应使用 /^\S+@\S+.\S+$/ 正则配合 @input 实时触发，避免 new RegExp 和 type="email"；需设置 inputmode="email" 与 maxlength="64" 提升兼容性与体验。
uni-app 验证邮箱格式，别用复杂正则，也别依赖 @blur 或第三方库的 type="email" 原生校验——小程序端不认、H5 表现不一致、iOS 微信里可能直接报 Invalid regular expression。
用这个正则：/^[^\s@]+@[^\s@]+\.[^\s@]+$/
这是目前在 H5 / 微信小程序 / App 三端都稳定通过的最小可用正则：
-
^[^\s@]+：开头不能是空格或 @，至少一个非空非@字符（用户名部分） -
@：必须有且只有一个 @ -
[^\s@]+\.：域名主体不能含空格/@，且必须带点（如 gmail.com 中的gmail.） -
[^\s@]+$：顶级域（如com）不能含空格/@，至少一个字符
它不验证 MX 记录、不支持 Unicode 域名、不检查是否真能发信——但够用。抄网上“最强邮箱正则”在 uni-app 里大概率挂掉，尤其是 iOS 小程序的 JS 引擎对 \w、\S 等简写支持不全。
@input 里同步校验，别等提交才看
用户输完 user@ 就该提示“邮箱格式不完整”，而不是等到点登录按钮才报错。所以校验逻辑要塞进 @input 回调，而不是 @blur：
-
@blur在微信小程序里经常不触发，尤其软键盘收起快时 -
@change在某些安卓机上延迟明显，甚至漏触发 -
@input是唯一每次按键后立即捕获值的方式
示例写法：
onEmailInput(value) {
this.email = value;
// 轻量同步校验
this.emailError = !/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(value) && value.length > 0;
}注意：只做格式判断，不发请求；只要 value 非空且不匹配就标红，空值不报错（避免用户一进框就看到红字）。
别把正则写成 new RegExp(/^...$/)
这是常见错误写法：
const reg = new RegExp(/^([a-zA-Z0-9_\-\.])+\@([a-zA-Z0-9_\-\.])+\.([A-Za-z]{2,4})$/);问题在于：RegExp 构造函数会把 /^...$/ 当字符串解析，而 ^、$ 在字符串里没意义，导致正则失效；更糟的是，某些小程序端会直接抛异常。
- ✅ 正确：直接用字面量
/^[^\s@]+@[^\s@]+\.[^\s@]+$/ - ❌ 错误：用
new RegExp(...)包一层，哪怕传的是字符串 - ⚠️ 若需动态拼接（比如域名白名单），用字符串拼 +
new RegExp(str)，但必须手动转义.、^、$等特殊字符
邮箱字段 type 和 inputmode 要配对
虽然正则兜底，但前端能拦住非法输入就少一次校验压力：
-
<input type="text" inputmode="email">—— 触发手机键盘的 @ 和 . 快捷键，iOS/Android 均支持 - 别用
type="email"：H5 会加原生提示，但小程序里被忽略，造成多端行为不一致 - 别用
type="text" inputmode="numeric"：会禁掉 @ 符号，用户根本输不了邮箱
顺手加个 maxlength="64"，邮箱地址 RFC 标准上限就是 64 字符，防呆也防恶意长输入。
真正容易被忽略的不是“怎么写正则”，而是三端运行时对正则引擎的支持差异和事件触发时机的不可靠性——@input + 字面量正则 + inputmode="email" 这套组合，才是当前最稳的落地方式。
