本文提供一个兼顾兼容性与规范性的 email 正则验证方案，解决下划线（_）被误拒的问题，并明确限制用户名和域名不能以特殊符号开头，同时给出可直接使用的优化正则及注意事项。
本文提供一个兼顾兼容性与规范性的 email 正则验证方案，解决下划线（_）被误拒的问题，并明确限制用户名和域名不能以特殊符号开头，同时给出可直接使用的优化正则及注意事项。
在实际开发中，使用正则表达式验证邮箱时，常因过度简化导致合法邮箱（如 username@example.com）被错误拒绝——典型问题就是原始正则 `^(?!.*)\w+([.-]?\w+)@\w+([.-]?\w+)(.\w{2,3})$主动排除了所有含下划线的地址，而根据 [RFC 5322](https://datatracker.ietf.org/doc/html/rfc5322) 和主流邮箱服务实践，**下划线_` 是用户名部分（@ 前）完全合法的字符**，仅需避免开头或连续出现即可。
✅ 推荐使用的改进正则（兼顾安全性与兼容性）：
^[a-z0-9][a-z0-9._-]*[a-z0-9]@(?:[a-z0-9](?:[a-z0-9.-]*[a-z0-9])?\.)+[a-z0-9]{2,}$说明与设计逻辑：
- 用户名部分：^[a-z0-9][a-z0-9._-]*[a-z0-9]
→ 强制以字母或数字开头和结尾，中间允许 .、_、-（避免 ._ 或 -_ 等非法组合）； - @ 符号：字面量 @；
- 域名部分：(?:[a-z0-9](?:[a-z0-9.-]*[a-z0-9])?\.)+
→ 每个子域均以字母/数字开头结尾，支持 . 分隔，禁止开头或结尾为 . 或 -； - 顶级域：[a-z0-9]{2,}（兼容 .app、.dev 等新 gTLD，不限死 2–3 位）。
⚠️ 重要注意事项：
- 正则无法 100% 覆盖 RFC 5322 全部规则（如带引号的本地部分），生产环境建议优先采用 SMTP 验证或专业库（如 Python 的 email-validator、Node.js 的 validator.js）；
- 浏览器端校验仅为用户体验优化，后端必须二次验证并发送确认邮件；
- 避免使用 .* 或过于宽松的模式（如 \S+@\S+\.\S+），易被恶意绕过；
- 若需支持国际化域名（IDN），需额外进行 Punycode 编码转换后再匹配。
? 总结：该正则在实用性与严谨性间取得平衡——允许下划线、拒绝危险开头/结尾、适配现代域名长度，适用于绝大多数 Web 表单场景。但请始终牢记：正则只是第一道防线，真实有效性必须通过邮件回执确认。
